Jump to content

itsthatguy

Members
  • Posts

    54
  • Joined

  • Last visited

Everything posted by itsthatguy

  1. 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.
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. 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?
  7. 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.
  8. 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.
  9. 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.
  10. It happens for me even when I disable the toolkit entirely
  11. 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.
  12. 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.
  13. 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.
  14. More Screenshots: When looking at the Sky or ground, the bugged areas are black or orange or green. Clouds still render properly, although there is some "delay" in the when the clouds re-render. Certain aspects of the cockpit (like indicators/displays) also render correctly, but again with a delay/smearing effect. Aircraft lights appear to render correctly. When in an external view, the same rules apply except when looking at the aircraft, it will be rendered correctly but only periodically. It will render the aircraft then get frozen and update again in a few seconds.
  15. See attached images. Only occurs when running OpenXR -> WMR. This has been reported before, OP then replied that the issue had been "solved" by using OpenXR -> SteamVR instead. The issue has not actually been fixed. Link to first time this was reported (in March...) Link to post with my issues pertaining to OpenXR -> SteamVR in MT MT_Artifact.trkdcs.logDxDiag.txt
  16. I can confirm that this issue still persists in the latest OB patch. Again, it's only when using OpenXR -> SteamVR in MT, it's not an issue in the ST version.
  17. Issue of phrasing on my part... the tool only goes from 0 to -100. You can't set a positive value. Let me correct myself: I've tried using the "shaking reduction" feature in OpenXR toolkit, but decreasing the value just makes it progressively worse.
  18. Just confirmed this issue persists in the latest update.
  19. I'm running a Samsung Odyssey+ headset. Running [OpenXR -> WMR] is suboptimal for me, as I like using reprojection and WMR's reprojection is terrible. Instead, I've continued to run either [OpenVR -> SteamVR -> WMR for SteamVR] or [OpenXR -> SteamVR -> WMR for SteamVR]. Either one works in ST, of course only the latter works in MT. However, trying to run the latter case ([OpenXR -> SteamVR -> WMR for SteamVR]) in MT causes nauseating camera shake. The rate at which my head turns isn't matching the rate at which the camera turns. It's like watching GoPro footage. Once again, this problem does NOT occur in ST with any combination of runtime and visualizer, and ONLY occurs in MT when using [OpenXR -> SteamVR -> WMR for SteamVR]. I've attached track/log files for the same short session, in the same Instant action. One in ST and one in MT. I've also attached my SteamVR video settings. System: i7-8700k RTX 3070 (Driver from 4/13, although this problem has existed through multiple driver updates) 32 GB DDR4 EDITED: I've tried using the "shaking reduction" feature in OpenXR toolkit, but decreasing the value just makes it progressively worse. MT_OpenXR_SteamVR_dcs.logMT_OpenXR_SteamVR.trkST_OpenXR_SteamVR_dcs.logST_OpenXR_SteamVR.trk
  20. Uploaded the wrong .log files, this has beed corrected. You'll find both dcs.log files attached above. Yes, I'm sure.
  21. Hi @BIGNEWY I'm using a Samsung Odyssey+ headset (WMR platform). I like running thru SteamVR because the reprojection is significantly better than WMR's reprojection. Running [OpenXR -> SteamVR -> WMR for SteamVR] causes camera shake effect, like watching Go Pro footage. There's a disconnect between how fast my head is moving, and how fast the camera is moving. It's very nauseating. It is happening between OpenXR and SteamVR, as the problem does not exist when running [OpenXR -> WMR] directly, nor does it happen when running [OpenVR -> SteamVR -> WMR for SteamVR]. Further evidence for this is that the shaking goes away during loading screens when I'm looking at the SteamVR loading area. I originally assumed that this was an OpenXR problem, but it turns out this issue only occurs when playing the MT version. It does NOT occur in ST. I've attached track/log files for the same short session, in the same Instant action. One in ST and one in MT. I've also attached my SteamVR video settings. System: i7-8700k RTX 3070 (Driver from 4/13, although this problem has existed through multiple driver updates) 32 GB DDR4 What else do you want/need me to provide to help narrow down the issue? MT_OpenXR_SteamVR.trk ST_OpenXR_SteamVR_dcs.log ST_OpenXR_SteamVR.trk MT_OpenXR_SteamVR_dcs.log
  22. Why is motion prediction only a problem in SteamVR + OpenXR? I looked, and Shaking Reduction is already at 0%. Adding any more seems to just make it worse. Every time I dig deeper I'm just more disappointed in OpenXR.
×
×
  • Create New...