itsthatguy

The smoke from the large fire effect renders on top of clouds, but turns white. When the smoke is on the edge of a cloud it kind of flickers or fades between black and white. (At least it does in VR, haven't tested flat screen). Using most recent "combined" release version. Seems like this is one more thing that needs updated to play nice with the new clouds.

I figured as much - the post was more of a comment on the unrealistic accuracy of the box. It's always spot on almost instantaneously after a radar is detected for the first time.

As far as I'm aware, right now the the Hornet's HARM TOO mode is like an HTS but with superpowers. I have no idea how the aircraft would be able to display a box over the emitter that the harm is "looking at" (the one that is boxed on the HARM display). In order to do that, the HARM would need to be able to give an accurate "look angle", which it should not be able to do. Determining the accurate position of a radar emitter is no trivial task, that's why things like the HTS exist. Here's another way to look at it. As we know, a TOO launched missile doesn't loft because the missile cannot determine range on it's own. But if it has an accurate "look angle", it (or the host aircraft) WOULD be able to calculate a range. With the current implementation, I can fudge a impromptu PB launch by finding an emitter in TOO mode, then creating a target point with the HUD and slewing it into the center of the box showing me where the emitter is. Now I have a relatively accurate aiming point for a PB launch. That should not be possible, not even an HTS in a Viper can give you an accurate position instantaneously, regardless of your approach angle. I'm not saying the box in the HUD is completely wrong, but I am saying that the way it's implemented right now must be. Also, why does the HARM in TOO mode have none of the restrictions that the HARM in HAS mode does for the Viper, like tables and scan time? The Hornet's HARMs can scan the entire volume for all types of emitters almost instantaneously.

Okay, let me make this more clear: There's me, and then there's most other people. I have tooltips off in my local DCS settings. When I join DDCS sever, tooltips are on anyway. When most other people (who have tooltips off in their settings) join DDCS server, tooltips are off. Why? EDIT: Follow up question: Tooltips aren't in the list of mission settings in the ME, so where in the world do you select whether to enforce tooltips when creating a mission?

Certain settings in MP, like tooltips and rudder assistance (for applicable modules) are forced on MP missions, but only for select people. I go and fly with friends and these things are stuck on for some of us and not for others. It's always the same people who have the setting forced. I'm one of them. For example, if I fly in the DDCS server I have tooltips forced on - when I ask about it others say they don't have the issue.

As far as I know from my own experiences and testing, anything classified as a "missile" is visible to radar and can be intercepted by certain SAMs. Anything classified as a bomb or rocket is completely transparent to radar, and cannot be intercepted by missiles or point defense gun systems. Why should a JSOW be able to be intercepted, but a 2000 lb GBU-31 not be? Why should a Hydra rocket be invisible to a C-RAM, but the same thing with a APKWS kit installed is able to be shot down?

I don't think this really belongs here but I wasn't sure where else to put this: The system requirements on the DCS download page have not been updated since the OB release of DCS 2.5, more than 5 years ago now. As someone who has been using the same system for almost 5 years (except for a GPU upgrade 1 year ago), these requirements are extremely outdated. -Performance dropped in the notorious 2.5.6 update -Performance dropped with 2.7 -Performance dropped with 2.8 -Performance on newer maps is worse -Performance is worse when using newer assets A GTX 1080 for VR? Sure, in 2018 back in 2.5.5 that worked great. Now that's laughably incapable - I should know, I had one up until a year ago. Please update the system requirements, because what is published on the website currently is a straight up lie.

Even with the recent improvements to OXR reprojection, it still pales in comparison to what you get when using OVR + SteamVR. I'd love to see OVR support for DCS MT.

UPDATE: I've discovered that this only happens when using OpenXR Toolkit's fixed foveated rendering. This still only occurs on the MT version of the game, so I'm hesitant to pin this on OXR Toolkit and call it a fix - not that anyone on the DCS side was working on fixing this bug anyway AFAIK. It would be nice to get a "We've seen your issue and are looking into it" or a "we're working on a fix" or a "we can't reproduce this" instead of crickets for VR stuff.

It happens for me even when I disable the toolkit entirely

This issue persists in the latest OB patch.

This issue still persists on the latest OB patch.

Yes, correct. It never happens in ST version, nor does it happen when using OXR -> SteamVR in the MT version, but that has it's own issues (for me at least). It only occurs in MT using OXR -> WMR. No matter what settings I use in the OXR Tools, preview/no preview, repro off, different types of repro, doesn't matter. The guy who first reported this 3 months ago had the same thing, so the issue isn't specific to my PC/setup.

Apparently editing the VR mask size now breaks IC check for no reason. Also a while ago I made a post about editing default CMS programs breaking IC as well, because there are no DTC's implemented and who likes having to set that up every time they start a mission or spawn in MP. That post has been completely ignored. Recommendation: if you're not going to make it an option to change in game, then don't make it break IC.

Clean (newer) driver install didn't do a thing. It doesn't make sense that it's a driver issue, as this is the only application in which this occurs. Specifically, only in the Multi-Threaded version when using OpenXR -> WMR.