Jump to content

M1Combat

Members
  • Posts

    1609
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by M1Combat

  1. 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.
  2. 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?
  3. 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 :).
  4. 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 :).
  5. 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...
  6. 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...
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. I don't think that's an option other than setting the mission to have no clouds at all.
  12. 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.
  13. 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.
  14. @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?
  15. 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.
  16. 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
  17. So the tracking for the G2 is mainly focused on red wavelength? Good to know :). Yeah having a few things hanging on the walls creating trackable shapes is good for sure :).
  18. G2 for sure. You'll run it just fine. Only pointer really is make sure you have enough light in the room for the tracking... Doesn't need to be like 6 60W lights or anything crazy.. just can't be super dark :).
  19. You mean in the OpenXR toolkit menu? I don't think it works there... You just need the keys.
  20. A 32GB static page file??? I just let windows manage mine but keep it in the right place.
  21. Oh... I thought you were suggesting the settings from your screen shot :). My bad
  22. I'd be fine with just an available or not in the ME and addable or not via the re-arm tool based on ME settings and current mission supply availability. Just like any other weapon... as far as time taken to equip/unequip... I'd say make it instant because ultimately "IRL" it would be added or not based on the mission and would already be there. This just isn't "IRL"... concessions need to be made. Actually... I'll be fine with however ED decide to do it :). I'm not making demands
  23. "the high set tail rotor creates a massive rotational force around the low slung tail boom" Not quite. Don't get me wrong... I'm not saying it creates no roll force. It creates a force that causes the airframe to rotate around the CM of the whole airframe and is affected appropriately by the fairly significant gyroscopes both in and on the whole package. It does not attempt to rotate around the tail boom itself. Forces don't react like that unless you build the tailboom out of wet noodles, but then you effectively just have two objects with their own CM's and we're well beyond the point now. The tailboom may indeed twist a small bit... but that's not because the tail rotor imparts a force that rotates "around it". It imparts a force in a direction and the reacted motion is defined by the forces relative location compared to the CM. It will produce yaw force relative to the tail rotor's distance from the CM, and roll force relative to the tail rotor's height from the CM... The shape and location of the tail boom have nothing to do with this aside from that they'll slightly change the location of the CM.
  24. I think we should just remove all the UK liveries for Trooper... Ban them. Expressly forbidden. Put them right next to the "cheat" category because clearly anyone wanting to use UK based liveries are just one step away from also messing with their files to add power as well so also ban the users too. Thank you drive through.
  25. Didn't we decide that all these settings have no effect or only negative effect (pre-render to 4) aside from "Prefer max performance" and maybe MFAA?
×
×
  • Create New...