July

Yes, the more modern SAM systems using PESA have good enough resolution and tracking that they don't need to actually enter a distinguishable CWI. I agree with you that mechanically steered arrays were significantly less performant compared to their PESA counterparts which is likely why they required multiple types of radars for the different phases of engagements. This is not to say that it could not be done. Now with PESAs, They use Track Via Missile (TVM) guidance by means of radio or datalink CLOS which is stated to have fire control and missile guidance capability during the search phase for midcourse updates and terminal guidance. MIM-104 Patriot A-F https://www.armyrecognition.com/united_states_american_missile_system_vehicle_uk/patriot_mim-104_surface-to-air_defense_missile_data_sheet_specifications_information_description.html SA-10A/B and by extension, SA-20A/B (Gargoyle continues to use upgraded variants of the Flap Lid, NATO reporting name: Tomb Stone), and SA-21 (Upgraded Flap Lid, NATO reporting name: Grave Stone) https://odin.tradoc.army.mil/WEG/Asset/S-300P_(SA-10_Grumble)_Russian_8x8_Long-Range_Surface-to-Air_Missile_System SA-11/SA-17 The CWI function was developed and included at the time for backwards compatibiltiy with the 1SB4M missile seekers found on the missiles of the SA-6 system. By means of PESA on the newer SA-17, it likely still uses CWI for terminal guidance. Whether or not it uses midcourse TVM in the SA-11/SA-17 is up for debate. This is by no means, a comprehensive list. It may also contain inaccuracies since official documents are incredibly scarce, and these are secondhand sources. https://www.ausairpower.net/APA-Engagement-Fire-Control.html#mozTocId158983 Traditionally, yes. However, TVM implies good enough search radar returns or pulsed tracks to support missile guidance before switching to CWI depending on the missile tech. No, I don't know how, nor claimed to know, exactly how the capabilities are implemented for each weapon system and likely never will. Like I said before, all we need are approximations if certain SAM systems are confirmed to be capable of TVM. That's all we need to know. Anything more would be overmodeling and would probably step over a lot of boundries. A lot of guesswork is needed, and it's ok if there are inaccuracies, as long as it stays somewhat realistic even if some aspects are "gamified". Somebody from my squadron who used to work on Sea Sparrow and carried out trials against Prowlers stated that certain frequency ranges would just be defined as "battle frequencies", and did not change the core behaviours of the RWRs. For DCS purposes, we don't need to know hard numbers. The tiny number of SAMs that we do have in DCS make up the vast majority of REDFOR LRAD. These behaviours you listed should also, DEFINITELY, be included. I won't argue against that. This all falls under the umbrella of an improved AI and a decent IADS system.

Of course it depends on the system, that much should be obvious. I wasn't trying to bring into question the way how more modern RWRs are appromixated in DCS. It was a lead-in to how RWRs could potentially be changed to reflect any new info and/or changes that come from having this discussion regarding expanded SAM system capabilities such as TWS weapons launch RWR indication behavior. In DCS, there are only three "steps" of SAM radars, reflected by our RWRs, only one of which will have actual missile guidance. Step 1: Target Search Step 2: Target Acquisition/Target Track Step 3: Missile Guidance/Illuminate Any SAM system in DCS, will not fire during the Track phase. This is reflected in our current RWRs when receiving Mud (Search), Mud Spike (Track), and Singer (Illuminate) tones and comparing them to the sites themselves, visually. The reason why this should matter to us as pilots is because there should be in theory, no way for an RWR to decide whether or not that there has been a missile launch and is being guided without treating all TWS indications as missile launch warnings. Unless if that's how that works IRL (I would be surprised if that's really how it works), we as the pilots should have to respect these kinds of threats according to their potential capabilities during the Track phase based on RWR indications. When being spiked by a SAM (i.e. Mud Spike, not Singer) it currently doesn't imply any kind of SAM launch because that's just how it's implemented in DCS at the moment due to what I believe, are undermodeled radar systems. I understand that the RWR does all of the signal and target sorting. If an increase in SAM system capabilities were to be introduced similarly to their IRL counterparts, we would still only need the same three approximations for the RWRs that we have in DCS. Whether or not a TWS-like mode falls into the "missile launch" category is based on whatever can be gleaned from information ED has on hand. Yes, that's how most semi-active missiles are guided. Whether or not this is all the way up and through the initial launch, mid-course, into the terminal guidance phase will depend on the system and the missile. There is only one detail that is important here with our approximated RWRs. Do these systems even have a TWS mode capable of weapon tracks? The answer to that is an extremely probable, yes, depending on the system. Details like the update rate, specific band, wavelength, etc are not as important and do not need to be modeled since you said it yourself best. We only care about what the RWR is telling us, not how it figures out what to tell us. Please don't be sarcastic. This topic is not meant to be a jab at ED or at my own efforts, that I will accept, might not even be acknowledged. This is a longshot at improving SAM systems that exist in DCS that could also lay groundwork for other systems added in the future.

I wasn't sure where to post this topic, so if there's a more appropriate place for this discussion feel free to move it as this isn't really a bug report as much as it is a problem with implementation. As you may know, the RWRs of a few different aircraft are not currently not picking up emitters properly and in some cases, only giving RWR tones when missiles are already in ranges close to terminal phase guidance. This issue brings up something more into question, specifically about the SA-11 with the 9S35 guidance radar for now but brings questions about other SAM systems including ones not implemented yet. Is the SA-11 Gadfly capable of launch in modes such as or similar to Track While Scan, only going into a continuous wave (CW) illumination for terminal guidance? According to publicly available documents, some of the higher digit Russian SAM systems are definitely capable of this including the latest modernization of the SA-11 TELAR tracking radars, the 9S35M (part of SA-17 Grizzly with PESA which is the upgraded SA-11). I'd imagine the version of the viper we have in DCS, F-16CM blk 50 RWR tones were designed with this in mind since it specializes in SEAD/DEAD. In real life, the RWR it has plays different tones at different rates to signify types of tracking radars and their pulsed modes. So, while the RWR thing in DCS is a bug, the way the bug plays out with the acquisition/tracking radar of the TELARs only giving missile launch warnings in the terminal phase (e.g. the tracking radar going "active" when missile is 3 NM away) could be a real capability. Some SAMs also have radars built into the nose cones but I'm not sure what missiles or what systems have them. This topic could bring future expansion and more realistic implementation of ground based SAM systems including an expansion of current system capabilities. This is not to say that any of the above have been implemented intentionally in DCS as of yet. Smarter RWRs likely have the capability that the F-16 RWR has of being able to differentiate different threat modes baked into the software for threat recognition. Not sure how ED would possibly get that kind of information though since I believe this falls into the realm of EW so what we have in DCS, in an aircraft like the F/A-18C are probably approximations. The above is an excerpt pulled from US Army ODIN TRADOC (approved for public release), corroborated by multiple, publicly available sources. https://odin.tradoc.army.mil/WEG/Asset/9K37_Buk-M1_(SA-11_Gadfly)_Russian_Medium-Range_Surface-to-Air_Missile_System This seems to imply that guidance before terminal phase is different, no? So the question is, are systems such as the SA-11 that we have in DCS (and maybe some other near-peer SAM systems) capable of firing on a tracked (but not CW illuminated!) target before going into a illuminated terminal phase track with semi-active missiles? If so, will we see this implemented into DCS? If not, why?

To use WMR + OXR motion reprojection, you have to use the OXR app that I linked above. There is a setting there you can set. Can't really recommend it though since it is so much worse than SVR motion smoothing Edit: If you have a 7000 series AMD card, motion reprojection is broken at a driver level.

I am still able to use SteamVR motion smoothing over WMR + OXR reprojection by setting SteamVR as the runtime in the SteamVR settings.

Do not use the --force command lines, you don't need them anymore so delete them from your shortcut. MT DCS is currently running on the OXR API, but for G2 users can be using either the SteamVR runtime, or the Windows Mixed Reality Runtime both of which are using OXR API. Without SteamVR installed, you either need to click "fix it" when prompted to in the Mixed Reality window when running an OXR app like DCS, OR you can use the OpenXR Tools for Windows Mixed Reality app to change the runtime to WMR. https://apps.microsoft.com/store/detail/openxr-tools-for-windows-mixed-reality/9N5CVVL23QBT?hl=en-us&gl=us Using the app, you need to go under the "Mixed Reality" tab, and change the runtime. Again, double check your shortcut to be sure your --force commands for MT DCS are deleted.

Personally on my G2, OXR + SteamVR runtime motion smoothing is literally the same as OVR + SteamVR runtime. Just being on the SteamVR runtime is enough to not have to use OXR on Mixed Reality's own motion reprojection (which is pretty bad imo) and instead use SteamVR's motion smoothing (same thing as reprojection basically) Yeah, not being able to use Reshade is a minus.

I see. What's the core issue here if people have to switch to OXR API and a compatible runtime for whatever headset they are using? Is it that there are still headsets without OXR compatible runtimes? In that case, yes restoring other API support is needed and was left out of the MT client.

So if I'm understanding correctly, headsets that run natively on OpenVR are getting CTDs because the new MT client is forcing OXR as the API? Whatever our runtime is set to shouldn't matter since the API will always be OXR now? Does that mean headsets like the Index and Vive running native OpenVR should theoretically not work on the MT client because OXR is now default in MT DCS? Is what's being said in this thread that OXR is the only functioning API?

Ok, I misunderstood. I can't help you with OpenVR, but for WMR headsets, this is how to stop CTD on the MT client when trying to use SteamVR.

The main fix here is to force SteamVR as the OXR runtime. I'll correct myself and clarify that I disable the toolkit based on preference. It is actually not needed. Attempting to run MT DCS with the command line --force_enable_VR --force_steam_VR without setting SteamVR as the OXR runtime causes CTD for me. Edit: I will also add that while this allows you to use SteamVR motion smoothing, due to compatibility problems with OXR, reshade and VRPerfKit don't seem to work (OXR toolkit does add built-in options for post-processing similar to reshade, and options that nearly mirror VRPerfKit, NiS, FSR, AMD CAS, and foveated rendering are available)

I have been able to force standalone DCS to run in SteamVR for WMR headsets by forcing SteamVR as runtime, and disabling OXR using the OXR toolkit app. I have not needed to add the command lines to the MT .exe shortcut. When starting DCS, it is important to not to press the "fix it" option that appears in WMR because that will set the runtime back to Windows Mixed Reality OXR and cause CTDs again. Edit: Set SteamVR as the OpenXR runtime instead of Windows Mixed Reality OXR by default. This stops the CTD. This also allows you to continue using SteamVR's motion smoothing over OXR's reprojection.

Curious to see what results other users are getting, AMD included.

Besides causing the rest of my PC to slow to a crawl and stutter, my frametimes did not go down after setting all process except DCS to run on E-cores only. The graph shown above is setting DCS from P-cores only, back to P-cores + E-cores. The frametimes didn't really go up or down, but as you can see I was seeing many more spikes when set to only P-cores. From my results, I can't recommend setting ALL OTHER processes to only E-cores, as it'll cause a lot of lag and QoL issues.

I will retest in a bit and report my results