M1Combat

The carrier is quite heavy. I'm sure you're getting a reasonable improvement pretty well everywhere else.

I've generally seen OXR be slightly lower FPS... But BETTER SMOOTHNESS anyway. The smoothness is what you chase FPS for... Not FPS. OXR gives better smoothness at a given FPS... So... If OXR is "very" close in FPS, it will be much better in smoothness. Which is what you think you want "FPS" for. You don't. You want smoothness. Anyway... AS Fiz says I'm sure you're just down into the lowest reprojection stage for some reason. There's something wrong. What CPU?? "With steam vr at 48% gives me 45ish FPS. I changed to open xr with toll kit. Motion projection on and 50% in dev tool." Wut? That makes no sense. Something is effed up. I run a 308012GB and I get real close to 60 everywhere but the boat with some options turned up... even shadows. On an od 3800X CPU running a super mild OC at 4.3Ghz. Slowdown when firing guns you say??? CPU doing physics? Does DCS use Phys-X? Are yo installing that with the driver? I'm not even sure DCS uses it... but slowdown with guns??? Odd...

You mean the Stable update? I would do a full on re-run through all of the steps for OpenXR installation on page 1. I think quite a bit has changed with OXR since the last stable update.

Great thread

100 Thank you.

I didn't look at your specs but will anything newish plug into your current motherboard? Do you have an AM4 board?

I didn't really mean that entire post jsut directed at you ;)... Kinda looks that way after taking another peak though :). I tend to switch gears in my head going into a summary and not tell anyone about it

Well... That's not going to work. That's called "Client Side Authoritative" and poses WAY more problems than the teency little edge case we're talking about here. I'd vote no on that for sure... unless as you say it has a server option where I can do client authority when it doesn't matter (I don't expect people to cheat) and server when it does (so I can't tell my copy of DCS that all bullets are hits no matter where I fire them...)... But then we're increasing the overhead of keeping the netcode up to date in the first place. Seriously though... We're discussing this based on a post made by someone who COULD HAVE SHOT DOWN THAT PLANE in my estimation about 15 times but was more concerned with saving ammo. This was the attacking pilot's CHOICE. Yes... it was also some netcode issues, but... we're not getting around that issue. Use a little more ammo. It's like a steel wall. There is simply no way to accurately predict the future. Keep in mind that in my previous example that's ONLY for client to server comms... there's also server to remote client comms... so either move it all to a 40ms ping for each client or... DOUBLE that 30' distance for two clients that have 80ms ping. Then add a few more for server processing time... And... 250MPH is also pretty slow so maybe throw in another 10-15' for EACH END of the comm cycle. You have multiple multi-million and indeed multi-BILLION dollar game companies looking into how to solve this problem in the best most competitive way possible. We're not there yet. It's simply low ping that's needed. Aside from that all you can do is try to predict. ED "probably" isn't the company that's going to solve this problem. The guy with the GUNS is...

Well... I would propose that the two different pieces of software have different priorities regarding their netcode... not that one netcode has "problems" and the other doesn't. I would bet that ED is trying to do a LOT more with their netcode and that if you tried to do the same with the netcode of the other software it may or may not work as well. We can't test that unfortunately. Don't get me wrong... I'm not white knighting... I'm only saying that I'm not 100% sure that's a safe assumption

Well... I'd like to see some evidence that the negative G's here would cause that... I mean they were already pretty slow through most of that interaction. Also... netcode will make direction change look a decent bit more abrupt than it actually is. That doesn't help much when we're talking about getting guns on because it just is what it is in regards to that but when you're also trying to add in the "instant fatality" (dramatized for effect...) argument I think it's worth separating what was happening on the local side vs. the remote side. I'd bet $1 that on the opposing pilot's side it looked perfectly normal from all points of view. 80ms latency... Just for example... At 80ms ping the plane travels just under 30' in 80 milliseconds at 250Mph. We all know that's not a super high ping and we also all know that 250Mph isn't that fast. It's already well into "The other guy effed up already anyway" speeds. That means that the remote aircraft, at 80ping and 250Mph, will appear to travel about 30' BEFORE you SEE it being affected by pilot controls. The remote aircraft needs to also remain fairly close to where it actually is in the remote players world so the netcode will adjust it's position and bring it back to where it should be. This creates more abrupt movement on the remote side. The magnitude of the difference will be almost directly based on ping and speed. I'm sure there is prediction in the netcode that attempts to keep them from doing really dumb things but at the end of the day (or direction change in this case) the aircraft on the remote end and the local end have to be pretty close to the same place... so it has to compress abrupt maneuvers into less time than they actually took... because it didn't know the remote aircraft was moving for about 30' after it started moving (again... that's at relatively low ping and low speed...). Another small example of this... in iRacing with an 80ms ping and a 200Mph brake point... You will see your opponent brake about 24' after they actually do. Then... The netcode needs to play catch up to try to synchronize where the car actually is between the local and remote systems so it ALSO makes the brakes appear to outperform what they could actually do. It also makes the turn in look much more abrupt (noticing any similarities???). It also makes it appear that the remote car missed the apex so you don't see how much of the curb they're taking. People watch iRacing alien replays when they are IN SESSION with those aliens and think "WTF!!!! How can that guy hit the brakes a full on 24' AFTER I CAN, has "super brakes" and then can't even hit an apex... but is 1/9 seconds per minute lap faster than me???". Well... they can't. And they aren't. If you run iRacing... someday ask an alien to provide a fast lap replay to you (some will) from a session that you were also in. Watch the differences between their replay of what actually happened and you replay of what happened looking through the netcode... VERY different things. Same here... but ED is dealing with speeds that are "a bit" higher than race cars. Anyway... this is a bad argument. Shoot better and you won't need to worry about what the other pilot is doing. There were like 15 times in that vid where the attacker could have killed the defender and they just didn't connect with the target. Fix that.

Definitely try the memcleaner as Edmuss suggests... Also try to get us concurrent traces for the CPU like you posted above for the GPU. Currently this - Appears to my eye to point to CPU issues because (and I'm assuming here...) it's all normal looking for in sim world stuff, then I think you probably exited to the menu/hangar screen which is where the drops to 0 happen, then... it kicks back in but to much more usage on the GPU as before... indicating that the CPU wasn't holding it back as much... as you'd expect in the hangar. So... Get us the CPU traces along with GPU traces and I think we'll find it's a CPU issue... but... exactly what issue will depend on the frequency of the peak/valley trace of the CPU. If it up and down like this GPU trace it's probably normal. If it's up and down at a much lower pace... maybe cooling or something?

Nice... Color me optimistic but I suspect there may be a few more things not in the patch notes that may help OXR installs go smoothly... Maybe... I've seen ED do stuff like that before :).

You're setting the permissions for that folder to allow any app that's currently installed or will be installed in the future... by you or by some malicious website or malware... to have write permissions to that folder. Sure if nothing goes wrong then you're fine... but it's a security feature. It's a small one... but it is one. Giving all users write access is less than optimal. Running a known trusted program as admin (or setting it to always run as admin if you like) is a much better solution. Do what you will with the info. I agree it's unlikely that you'll ever suffer the consequences of doing that... but now you can :).

I mean yeah that will work... but please don't do that. This is a windows security feature that you're breaking :). I mean I get it... there's LOTS of other security "windows" in windows... but still...

So you can't actually up-scale in the traditional understanding of the term? only downscale? Why? That doesn't make sense to me. /EDIT Ok N/M I get it... The idea is to use upscaling as an offset and target display resolution for adjusting "super sampling" basically...

yikes... I'd put those back after the install but try to keep it super clean... like do a custom install and make sure you only install drivers and not extra bloat ware if they include any. Being AMD I suspect they won't but just in case. that said... maybe windows update had newer ones but I tend to not trust MS supplied chipset drivers.

I would go through the install steps with "every" step completed (not assuming "Oh I did that before") and let us know. Also there's an OXR discord that they get to more than the DCS forum.

You can save your user profile (saved games\DCS) or something like that. I also recommend STRONGLY that you export your controller configurations EVERY time you re-map something.

LOL... I only saw ONE questionable juke there... it was pretty early and did look to be caused by network prediction code but... I just don't see anything there being a problem. Have any of you ever been shot at? I mean I think the pilot is well strapped in... I've been on amusement park rides better than that. OK maybe not really but... I don't see much there to complain about.

I don't think that's an option other than setting the mission to have no clouds at all.

That's fun... I'd bet it's been bound to something in the general or ui section or something? one of those sections that aren't related to a specific aircraft.

Thank you... I suppose it "probably" does but I'm not sure... I know the desktop shortcuts that steam creates are more of a trigger to steam that passes the game ID, then steam runs the exe... so it "should" just work... but who knows. I'm with you though... best to move to the standalone openbeta IMO.

@jomonto I think you might not have DCS set to run in VR??? Are you running steam DCS? they're functionally the same but I'm not 1000% sure steam based DCS can run OXR unless you run the exe without triggering it through steam? I'm not sure though take that with a grain of salt. @nikoel @edmuss Hey does openxr work with steam versions of DCS?

I think the new versions are better. I'd wait. I suspect it's probably a temporary issue with something in the chain being down.

Makes sense. Honestly though... I'm in a somewhat dimly lit area (like one 40 watt light) and I have a 46" monitor at barely arms length in front of the headset and it works fine anyway so... It's not like the tracking on the G2 is bad anyway