itsthatguy
-
Posts
54 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by itsthatguy
-
-
2 hours ago, Hulkbust44 said:
I did just confirm that the TD box (Priority target symbol) is calculated and displayed by the CLC.
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.-
2
-
-
8 hours ago, Tj1376 said:
And what are your settings for tool tips?
Some mission designers enforce settings. Some leave it up to the client.
Your settings may be tool tips are on and DDCS may have tool tips set to client preference and thus yours are always on.
Some servers enforce a setting (like tool tips must be off. Or they must be on.)
Really comes down to a combination of factors you have to consider.
TJ
Sent from my SM-N970U using Tapatalk
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?-
2
-
-
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.-
2
-
-
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.
-
2
-
-
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. -
On 7/29/2023 at 6:11 AM, MoleUK said:
This has been my experience when using Virtual desktop + Steam VR + OpenXR toolkit as well.
Works fine when using OpenXR toolkit via oculus link. Will try playing around with the settings more later to see if it's fixable.
Edit: Disregard, it's actually only while the toolkit menu overlay is open where the camera shake occurs.
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.
-
7 hours ago, YoYo said:
So for ST version and SteamVR is it ok for you? Btw. did you install the last OpenXR Developer Tools?
You can tick disable NV flow option for DCS:
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. -
13 hours ago, YoYo said:
Sorry but I never noticed it, I was on G2 too. Looks like driver issue maybe. Do clean install of driver with DDU, install only driver without any NV Experiance etc. Maybe any mods does it?
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.
-
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.
-
Issue still persists @BIGNEWY
-
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
-
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.
-
1 hour ago, Xtorris said:
Using a positive value will make the shaking worse.
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. -
Just confirmed this issue persists in the latest update.
-
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
-
29 minutes ago, Baldrick33 said:
@itsthatguyAre you sure you aren't running OpenVR using the ST version?
Can you attach the dcs.log file from running the ST version?
Uploaded the wrong .log files, this has beed corrected. You'll find both dcs.log files attached above.
Yes, I'm sure. -
On 5/5/2023 at 3:14 AM, BIGNEWY said:
I have passed on the feedback but can make no promises for openVR sorry.
Can someone test this also
set your OpenXR runtime to use SteamVR. Open SteamVR > Settings > Enable Advanced > Developer > Switch OpenXR runtime to SteamVR
what results do you get?
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
-
On 4/30/2023 at 5:04 PM, YoYo said:
Exactly SteamVR+OpenVR rules
, we need it for MT as well.
About point 4. Check what you have in OpenXR Toolkit Input section. You need to have Shaking reduction, formerly Prediction dampening = 0% for SteamVR and OXR.
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.
Smoke from Large Fire Effect Doesn't Like Clouds
in Weather System Bugs & Problems
Posted
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.