Vortex225

Not a full answer to your question, but I recommend you use OpenXR Tools for WMR (to control HMD resolution) and Quad Views Foveated to get the best performance boost without eye tracking. OpenXR Toolkit is popular too, but I prefer the combo of the two above for best performance and visuals. https://youtu.be/NZVp7Ya1GZM?si=pUpKIfwiXXvsmbVw As for DCS settings, I would start with the VR preset and work upwards from there. Good luck!

How do you manually update DLSS for DCS again?

Update/Edit: I figured out how to disable Turbo Mode for QVF on my Reverb G2 thanks to the QVF Wiki and Str][kerTV's YouTube tutorial. While the default settings do work well overall, I found that motion reprojection wasn't working properly until I disabled Turbo Mode in QVF and enabled it via OpenXR Tools for WMR. Problem solved and I'm very pleased with my results using QVF! Question for @mbucchia on the Quad Views Foveated (QVF) app. Which app is the best to enable Turbo Mode (does it even matter?), and how would I disable Turbo Mode for a G2 in QVF if I want to enable it via OpenXR Tools for WMR? Background: I'm a Reverb G2 user (no eye tracking), and I'm using OpenXR Tools for WMR to adjust resolution, turn on motion reprojection, and enable Turbo Mode (instead of through OpenXR Toolkit). However, I do use OpenXR Toolkit to enable CAS sharpening (100%) and fixed foveated rendering. I plan to try your Quad Views Foveated app for the first time, but it's my understanding that Turbo Mode is enabled by default in the app and will cause conflicts with other apps that enable it. I would like to continue using Turbo Mode via OpenXR Tools for WMR, because it's my understanding that version works best with motion reprojection (which I use) and the OpenXR Toolkit version does not. Thanks in advance for your help and, of course, for these awesome VR tools for our DCS community!

I agree that this is a significant change that needs to be documented a bit better to help us understand. I'm still struggling to use this properly in my AG workflows for both DTOS and VIS--even after Lord Vader was kind enough to explain it to me. What entry are you referring to? Is this something in a recent change log? ETA: Found it, my mistake. The single SPI logic update was documented thoroughly here; however, we may need a few tutorials to help us understand how to use it properly. https://forum.dcs.world/topic/209147-viper-mini-updates/?do=findComment&comment=5288681

@Lord Vader Ok, thank you for taking another look. I do understand what you're saying, and I will accept it as working as intended. Please know that it was not my intent to be difficult; it was simply hard for me to understand how these refinements could reflect reality when they ostensibly provide less situational awareness and require more HOTAS presses and/or MFD button interactions than the previous implementation. All that matters is realism. If you're saying these changes were intentional, then so be it. Thank you again for your time.

Thanks, @Lord Vader. I do appreciate you taking the time to provide a detailed and thoughtful reply. I think we may still be misunderstanding one another, so I took time to carefully read your post today and review all applicable DCS material I could find relevant to this issue. Please note that my observations may be distinct from the other issues raised in this thread. To this end, I would like to make another respectful and earnest attempt to explain the steerpoint issues I feel are not behaving properly for the Viper in DCS 2.9.0.47168 Open Beta. Terms and Definitions: To begin, I want to avoid any confusion about terms, whether I am mistaken on definitions or otherwise. To clarify, I understand the steerpoint diamond as the diamond visible in the HUD or HMCS that shows you the location of the currently selected steerpoint. In the tracks I uploaded, this is always steerpoint 1. Additionally, I understand the TD Box to be the box and dot that that is visible on the HUD or HMCS that shows the location of the current target designation/SPI. Scope of Discussion: To simply our analysis, let's restrict the discussion just to VIS mode for the moment. Please consider the following graphic, which is numbered according to the order in which the screenshots were taken: #1 shows the HUD view after initially selecting VIS sub-mode with the steerpoint diamond clearly indicating the correct location for Steerpoint 1. The TD Box is caged to the HUD because I have not yet slewed it to a desired target location. #2 shows the HUD view after slewing the TD Box to a target location chosen arbitrarily for this demonstration track. I have already pressed TMS FWD once to designate and ground-stabilize the TD Box to that location. Notice the missing steerpoint diamond where it was previously located in #1? #3 shows the HUD after I have reset/re-caged the TD Box back to the FPV with TMS AFT. Notice how the steerpoint diamond has shifted to a new location? I haven't modified the currently selected steerpoint; and yet, the steerpoint diamond is now located where the TD Box was previously designated from #2. The correct location for Steerpoint 1 is annotated for comparison. #4 shows the HUD view immediately after selecting the PRE sub-mode; no other changes have been made. Notice how the target designation box now correctly reflects the location of Steerpoint 1, which makes sense for a PRE delivery. The steerpoint diamond is occluded, but I believe that is intended based on another video from Wags showing JDAM deliveries in PRE. The second screenshot below (single HUD view) shows a frame from Wags' video DCS: F-16C Viper | Air-to-Ground Helmet, in which the VIS sub-mode is used for a standard JDAM attack. Please note the presence of both the steerpoint diamond (showing the location of his Steerpoint 2) and the TD Box in the HUD/HMCS at the same time. In summary, I'm describing two separate issues. - The first issue is shown in #2 below. Why does the steerpoint diamond disappear? See the second screenshot below (single HUD view) from Wags' video for what I think the correct behavior should be. Please note that I could not find any reference in any DCS Open Beta patch notes that describes a change to steerpoint diamond symbology that would have modified the behavior away from that depicted in Wags' tutorial video. - The second issue is shown in #3 below. Why does the steerpoint diamond shift to a location other than the currently selected steerpoint? I interpret the HUD picture in #3 as Steerpoint 1 is at the location of the diamond, but I *know* that Steerpoint 1 is actually located in the position from #1. This seems like a bug to me. Thank you again for your time and consideration.

Just following up to say I haven't noticed this particular issue with markpoints since the hotfix; it seems to have been fixed with the hotfix. Nevertheless, I'm having trouble with steerpoints in VIS and DTOS modes and I'm working through the troubleshooting in another thread.

Hi, @Lord Vader--and thank you for your time and consideration of the tracks. While it is certainly true that module features can change after a tutorial video by Wags is produced, the change we're talking about is a pretty significant shift in HUD/HMCS functionality. Losing the steerpoint diamond symbol on the HUD and HMCS is a degradation of situational awareness during an attack; you lose an import navigation reference. One would reasonably expect a change like that to be carefully documented; and to your second suggestion, there is no reference to steerpoint symbology removal when a TD Box is created in the patch notes for either DCS 2.9.0.46801 Open Beta or DCS 2.9.0.47168 Open Beta. Finally, I'll add that issue #2 (i.e., moving the steerpoint to the location of the previous TD Box) surely cannot be an intended feature change. And if that's a bug, it stands to reason that the steerpoint symbol being removed, covered, or obscured (issue #1) while the TD Box is visible is likely connected or related from a coding perspective. I do very much appreciate the engagement. I sincerely hope this bug can be investigated and resolved.

@Lord Vader @Raptor9 Thank you for your help, but I do believe something is not working correctly with steerpoints right now. I was able to observe this bug tonight for both VIS mode and DTOS. Issue #1: When creating a target designation with TMS Forward in either mode (after ground stabilizing), the steerpoint symobol will disappear. To verify this was not working as intended, I watched Wags' tutorial videos on DTOS and VIS to confirm the steerpoint symbol should remain visible in the HUD (or HMCS) after creating a target designation; his videos confirm they should for both DTOS and VIS (link to timestamps showing the correct behavior). In both videos you can still see the steerpoint symbol in the HUD even after creating the target designation with the HUD or helmet. Issue #2: Steerpoints are moved after clearing the target designation. If you attempt to CZ the SPI back to the steerpoint (using TMS Aft to clear that target designation and return the cue back to the HUD), the currently selected steerpoint will shift to the position the target designation was previously located. In summary, I believe this bug is both removing the steerpoint symbol when the target designation/SPI is created, and it is moving steerpoints in both the HUD and HMCS after the target designation is cleared. I have been able to reproduce this on multiple terrains and in both single player and multiplayer. I have attached two trackfiles that indicate the problem, one each for CBU-87/97 (DTOS) and another for CBU 103/105 (VIS). DTOS_bug.trk VIS_bug.trk

I'm almost positive this is was the behavior I observed last night. Couldn't quite figure out what was happening, but this is a close match to what I observed with the HAD and HTS. Once I switched back to NAV mode, the waypoint symbol went back to the correct location.

Indeed, but this is not the behavior I observed with the penultimate version. I regret I haven't had time to test the hotfix version or create a track file, but I hope to do that tonight. Take your description (which is the correct behavior as far as I know), but now consider that the markpoint is not saved where the markpoint symbol is located & ground stabilized the moment you press TMS Up (short) the second time. Instead, it saved it to where your HMD was centered at that moment. That's what I was observing.

I'm not the OP, but this is a good description. Thanks, Raptor9. On the subject of markpoints via HMCS, was the behavior changed in the Viper for 2.9? I noticed in my testing last night that after slaving the the markpoint cue to the HMCS, it would save the markpoint to the location my helmet was looking at when pressing TMS forward the second time--not the location it was ground-stabalized to on the first TMS press. I only noticed this because my TGP wound up looking somewhere entirely different than planned. I intend to submit a bug report soon with track file, but ran out of time to test last night. Thanks.

I have a replica force-sensing Viper base and grip from Realsimulator, and I don't notice any input lag at all. It feels smooth and hyper-responsive to me. I use completely default axis settings in DCS for it too; no saturation of curvature. However, I did notice that something felt off when I was previously using a traditional cam and spring joystick and base. Maybe your hardware is creating that feeling?

Tried out the FM changes ED listed in the 2.9 patch notes. My first impressions were very positive. I could be wrong (will defer to those who have tested it longer or more thoroughly), but the jet seemed to retain and gain energy better in high-G 2C flows against the AI. I actually had to come out of blower several times to avoid blackout or going well above optimal rate speeds. Overall, the Viper in 2.9 feels like it better matches the expectations provided by Mover (i.e., a real Viper driver) in his last FM review on YouTube 5 months ago. I'm pleased and curious to hear everyone's thoughts. *Just a friendly reminder to keep the conversation civil and at the unclassified, publicly releasable level.* "Improved FM: -The characteristic of the displacement of the pressure center during the transition to supersonic has been corrected. -Improved the characteristics of turns at high altitudes. Smoothed the effect of 'bubble' when passing the transonic zone on a turn at high altitude. -G-onsets transition characteristics improved over the entire range of heights and speeds."

All good. An option would be great, agreed.

I think it's important that this change, if ever pursued, should only be an option. I have a force-sensing stick from Realsimsulator and it works beautifully with the current control implementation for the DCS Viper. Coming from several "high-end" cam/spring bases from Virpil and VKB, my upgrade to a force-sensing solution was a revelation and transformed my enjoyment of the module. I even prefer it now for other modules like the Tomcat and Apache. In other words, please don't change things for those if us with compatible simulation hardware.

Completely agree with OP; a proper force-sensing stick makes a tremendous difference for the DCS Viper module. I love my Realsimsulator (RS) R3L and recommend it to anyone who flies the Viper regularly in DCS (or BMS).

This could be your HOTAS. With my previous sticks (Virpil WarBRD and VKB Gunfighter Mk 3), the Viper felt laggy and weird compared to the Hornet. I recently upgraded to a Realsimulator FSSB R3L, and now the Viper feels amazing and extremely responsive with force sensing. Ironically, now the Hornet feels mushy and laggy for me by comparison. I agree with BN; I think it's fine as it is now.

Actually, I did a quick test after 2.8 was released and found them to be working better. Both CCIP and toss bombing appeared to be reasonably accurate with the CBU-97. They definitely weren't working correctly before 2.8. Haven't tried them since the hotfix, so it's possible the changes were reverted.

Now that we have the correct ACM BORE HMCS behavior in the latest hotfix, which works just fine for me, I have two questions (not a bug report): 1) I'm noticing that I have no reference for when the ellipse is outside of the valid LOS range for the FCR. However, how are we supposed to know when we've moved the HMCS LOS too far to allow TMS Up (long press) to lock the target? Should the ellipse be dashed or crossed out or something to tell us the HMCS LOS is out of gimbal limits for the FCR? 2) Why does NO RAD show above the ACM BORE ellipse in the HMCS when we press and hold TMS up? Is this correct/intended? Thanks in advance!

Agree that VAICOM Pro is essential, especially for VR users. Came here looking for a solution. My wingman and I can't get it working either and we're not sure what to do at this point. I can't even get regular comms to work at this point either (even with VAICOM completely closed)

I have the RealSimulator FSSB R3L, which is similar to your stick and also force-sensing. You shouldn't have to set any curves with a good force-sensing solution. The response is naturally very smooth and precise, and the sensitivity should be adjustable outside of DCS. If you're encountering PIO, I recommend tuning your sensitivity downward so that the force required to reach max deflection is higher. As for the deadzone near the center, the RealSimulator software has a breakout force setting that controls how much force is required to overcome the center deadzone. My guess is that you probably have a software setting you could adjust to make it easier to breakout of the deadzone.

Edit: adding three short tracks on Caucasus to demonstrate the issue for CCIP, CCRP Loft (i.e., toss bomb), and a level CCRP drop from medium altitude. The CCIP and toss bomb attempts score zero hits and fall notably short. The level CCRP drop gets closer and scores 1 or 2 hits but the majority of submunitions fall short. This isn't a bug report per se, because the issue (or something related to it) has been reported here. However, the issue with CBU-97s falling short when using CCRP loft is making it hard to enjoy the new toss bombing symbology for the Viper. They even fall well short of the intended impact point when using CCIP. As I mentioned in the linked thread, it's almost as if they would be on-target if it weren't for the submunition separation and parachute phase, which modifies the normal trajectory below the burst altitude. Other bombs seem to be working great with CCIP and CCRP. CBU-105s also seem to be working as intended. This is frustrating because the CBU-97 is one of the most capable and entertaining munitions to use in DCS, and it's one of the things that really sets the Viper apart from its multirole peers in the sim. Accurate CBU-97 bombing with the Viper is pretty important in my humble opinion, and I hope this gets fixed soon. Any word on progress? Thanks in advance! cbu97_falls_short_CCRP_Loft.trk cbu97_falls_short_CCIP.trk cbu97_falls_short_CCRP_Level_Drop.trk

Can confirm this is happening for me as well (back seat in multiplayer with a human CPG). Works fine as backseat when in single player or in a multiplayer server with George as CPG. This only happens to me with a human CPG.

I've also noticed the upper and lower altitude search limits don't update when you enter Spotlight mode. Although it is nice now that Spotlight places you into SAM and not STT.