Rifter

Perhaps the smaller guys are modelled correct according to the time they lived whilst the bigger ones represent todays average male size? But even if that would be the case the difference in size seems quite a bit off…

Bump!

Breaking news: Taz1004 the Tasmanian Texture Devil did some devilish good optimizations with impressive VRAM reduction. https://forum.dcs.world/topic/323252-dcs-optimized-textures/

Every VR ecosystem has its own implementation of motion reprojection - it is part of their IP. There is no cross-usage of those implementations possible. One would have to reverse engineer a VR system to do that. Motion reprojection can be set to permanently on/off or can be set to be activated when a certain amount of fps is not reached. Those settings can also be set outside of a VR ecosystems (in SteamVR or OpenXR Toolkit) - which obviously confuses a lot of people. Historically DCS supported OpenVR (SteamVR) and LibOVR (Oculus). DCS never supported WMR so there was no other way to use a WMR Headset (like a G2) than via SteamVR. That had always being a pain because the WMR plugin for SteamVR was not a masterpiece performance wise. It was a kind of ‘lost in translation’ thing. With DCS now supporting OpenXR all of that should be history because all VR ecosystems have OpenXR implemented and can now be run native by DCS. So if motion reprojection on a G2 performs better with SteamVR (OpenXR) than with WMR (OpenXR), there must be something wrong with the OpenXR API implementation on the WMR side. It would actually mean that the chain DCS —> OpenXR —> SteamVR (WMR OpenXR) —> WMR motion reprojection ( = OpenXR via SteamVR as a fallback) works better than DCS —> OpenXR —> WMR (OpenXR) —> WMR motion reprojection (= native WMR OpenXR path) Hence on a WMR device there is no DCS —> OpenXR —> SteamVR (OpenXR) —> SteamVR motion reprojection The up-scaling technologies FSR and NIS have nothing to do with motion reprojection - they can be used according to your own taste and you can always decide to use motion reprojection on top of that.

I have no doubts about your specific experience - I’m very well aware of the fact that some people observe severe problems here. But that has nothing to do with the usage of a ‘good working version’ of motion reprojection versus a ‘not so good working version’. There is a big misconception that motion reprojection is something which can be changed by the user or applied as an alternative. As a G2 user you only have the opportunity to use the WMR version of motion reprojection. SteamVR motion reprojection works only for Vive and Index. Asynchronous Space Warp only applies to Oculus/Meta. And OpenXR Toolkit has no motion reprojection solution to offer at all. Selecting the option motion reprojection for a G2 in SteamVR or OpenXR Toolkit does not - surprise, surprise - select a specific motion reprojection variant. It just tells WMR to switch on its motion reprojection. SteamVR and OpenXR Toolkit only act as a frontend to the WMR Runtime. I have different VR headsets and therefore always edit the windows registry for the desired VR runtime. This can also be done by a tool: https://github.com/WaGi-Coding/OpenXR-Runtime-Switcher It does nothing else than setting the registry to the selected VR runtime. Never experienced any ‘wobbling mess’ with my G2 *). Never experienced differences in motion reprojection quality no matter in which tool I switch it on. I want to apologize for my wording ‘placebo effect’. I did not want to offend anyone. I know that VR can be a pain in the <profanity>. But it is of no help when problems are broken down to the wrong causes. That just creates esoteric and snake oil solutions. *) I tested a 6900 XT some time ago. That created a wobbling mess for all of my VR headsets when using motion reprojection. But that is due to the fact that AMD cards are not so suitable for that specific VR functionality. No problems with my 3090 at all.

Motion reprojection (asynchronous space warp, etc.) is respectively the proprietary implementation of the different VR device manufacturers. It runs fully within the VR software. The motion reprojection of SteamVR cannot be used as an alternative to WMR reprojection on a WMR device. If someone thinks otherwise, I’m looking forward with great expectation to the technical explanation for that. Also I’m not aware of the fact that OpenXR Toolkit delivers its ‘own’ motion reprojection implementation as an alternative to the native motion reprojection of WMR. Even the dev of OpenXR Toolkit (mbucchia) was perplexed by the user reports about different behaviours (ghosting, stuttering, ...). OpenXR Toolkit just sets a registry key that enables the setting from OpenXR Tools for motion reprojection in WMR. If anyone experiences differences in motion reprojection depending on his settings back and forth (SteamVR - WMR - OpenXR - whatever) that is a pure coincidence or something else (probably some other mess on his machine).

To be even more pedantic: SteamVR motion reprojection cannot be used on anything else than Vive and Index devices. WMR VR headsets cannot be run with SteamVR in terms of a WMR replacement - they can only use SteamVR as a frontend to make use of WMR functionalities and to allow a per-application control setting. Motion reprojection itself will just be handed over to WMR. There is an unbelievable amount of placebo effect user reports on the forum like ‘when I use SteamVR motion reprojection on my WMR device it runs better/smoother’.

In the resent past sniper pods on the C-model enhance the air-to-air capabilities. This creates the ability to identify targets without using radar. Especially when the target cannot be tracked by the radar because it is a stealthy aircraft. We are talking about AIM-9X employment by the way. The sniper pod acts as a capability boost here.

!?!?!? This sentence denies the fundamental principles on which our whole universe is build on - the physical laws. I spend 30 years in the industry as a development engineer and I never stumbled over a single piece of technology in which a gain of capabilities could be achieved without any trade offs. There is no such thing as a win-win situation in technical systems. The simple rule for every piece of technology in the The Real World is: The sum of all inconveniences in a technical system always remains constant. The only freedom you have is to decide which kind of inconvenience you are willing to live with. Let me therefore correct your sentence for you: It's not like in The Real World where there is always a sacrifice of one thing for the gain of another; more often than not in games there is a gain of capabilities for no real loss. Your welcome!

I think it was JFK who said: "We choose to master the F-104 radar system in DCS not because that is easy, but because that is hard."

On my side OpenXR @100% will show a per eye render resolution of 1648 x 1776 pixels or 1504 x 1616 pixels for the Rift S depending on the setting on the Oculus side of either ‘Quality’ or ‘Performance’. Those resolutions are Rift S standard for 100%. OpenXR does not touch my Oculus render resolution by default. It also does not override OTT or Oculus Debug Tool settings, nor DCS settings. I have to chance the 100% value in OpenXR explicitly to force OpenXR to manage my resolution.

At the moment the MT version of DCS forces the use of OpenXR with Oculus. Start with native Oculus is not possible with MT. So if the use of OpenXR causes stuttering on the Rift S nothing can be done against that right now. The standard version of DCS has none of those restrictions and works as before.

When I’m not flying the Tomcat I’m flying the Yak with this livery. I like well worn stuff…

What I would like to know on the topic of the new forge elements: Were falling off buttons a thing from the very beginning when the Tomcats went into service or did that start to happen when the jets started to age and got rattled apart more and more? My wife is great fan of the Top Gun movie. When I once showed her the DCS Tomcat cockpit in VR, she said it would look like a scrap heap and said it would totally destroy the whole Top Gun legacy and she refused to believe Tom Cruise sat in such a cockpit. She was especially disgusted by the ‘shabby textile stuff' strapped over the instrument panels and said ‘I don’t want to know whats living underneath of it’. And now when ever I fly the Tomcat and my wife is around she asks ‘Are you flying with that scrap heap again?’.

According to the sounds of pain on the forum the last big VR performance drop occurred when DCS went from 2.7.x to 2.8.x. Looking at the feedback in the forum the latest update (single thread version!) did not result in VR performance break-ins - in a lot of cases it seemed to be the opposite. From my own experience the Rift S can be a pain in the a$$ with regards to sudden performance drops (mostly stuttering) because of updates (be it a Windows update, an Oculus/Meta update or a DCS update). If everything was fine before it is not advisable to try every performance gaining hint and tip which can be found on the forum. Make sure that your Nvidia-driver is the same as you had a couple of month ago (when you last played DCS and everything was smooth). You don’t need the newest driver to assure performance (the opposite can be the case!). Check your DCS settings carefully - perhaps something was cranked up in course of the update or one of your old settings has to be adjusted. Also check wether device hot plug is off. Check memory usage - perhaps the newest DCS version is more memory hungry - you only have 16GB. You could also roll back the DCS version to see wether it’s really the newest version which causes the problems. Check update history of Windows and Oculus/Meta (though for the latter it is hard to make a rollback). If the new DCS version is not the naughty boy something else must have been changed on your system.

From my experience most motion system vendors don’t understand the basic physics of flight and the associated forces on the pilot. They grew up with sim racing. In most situations during a flight there is only the normal force acting on the pilot. No sustained lateral forces, no sustained rolling forces, no sustained pitching forces. So if you take yourself the time to modify the default settings to something more meaningful you will definitely create a lot of immersion. I use a simple 2-DOF platform (next level racing). Out of the box it’s terrible. After I modified everything it’s now like my initial VR experience - there is no way back. Hence that without VR the motion experience is very limited and not worth the money, because in VR you don't have a reference for the movements and therefore your brain gets totally fooled.

Tree shadows are not visible from distance until flying over them. Buildings are not affected. Seems the latest update messed this up (or it always had been like that and I just didn’t realise). All other maps create a soft fade in effect from the distance for tree shadows. This is the case for both flat and default terrain shadows. View distance settings don’t have any influence.

Hey rato65, what an awesome mod - since the DCS Huey feels a little abandoned at the moment your work is much appreciated! Just one small wish: Could you make a variant which just adds the nose without twin engine cosmetics? That would represent the ‘Huey II’ which is basically an enhanced UH-1H. Did you choose one of the predefined loadouts? Before that you won't see anything...

The new cockpit is a… …BLAST!!! I fly VR only and this cockpit is finally a worthy fit for this great Mod. Kudos to PeeJott and his crew. The icing on the cake would be a F-104 specific radar (like in the F-4 Mod) to get rid of the F-15 stuff.

The wording 'gear struts overstressed' might be misleading for the ED team. Hard to tell wether the compression damping on touchdown is too soft compared to reality. But from the video the rebound damping seems to be too big, since the wheels lose contact to the ground although the maximum downward travel of the gear would allow to stay on the ground.

Sorry SkateZilla, no offense, but you just triggered me. In VR I do my adjustments based on the occurrence of motion sickness and immersion breaking frame rate drops. At some point I realized that an insignificant minority of VR users on the edge of the bell curve seem to be robust enough to go without reprojection and are fine with frame rates below 90fps because they feel they still have enough ‘gameplay smoothness’. For the vast majority those user reports about having a satisfying VR experience without having 90 fps (or on my account 80 in case of a Rift S) are unfortunately useless and misleading. Or to stick with your phrasing: 1% of the players are so unaware of their individual and unrepresentative non-susceptibility for motion sickness, and honestly that's the fatal flaw with their assessments in VR.

So you lucky devil startet with a sim pit and a projection system into your flight sim career. I haven’t even reached that point nowadays…

He will only have problems when the Eagle driver is clearly above average. But I guess the typical DCS Eagle aficionado is above average, so…never mind. For the sake of a balanced opinion, here are some statements from Chuck Magill (USMC Hornet pilot, later USAF F-15C pilot) comparing F-15 to F-18: ‘You don’t really want to get into the visual arena in the F-15.’ ‘In the hornet we wanted to get in the visual arena because then we thought we had an advantage.’ ‘But I did learn if you got the nose low it didn’t have the responsiveness of the hornet. You didn’t want to get low and slow with the nose down in the Eagle.’ ‘You did not have the high alpha capability that you had in the Hornet. What you had though was an extraordinary amount of thrust on a 9 G airplane and that’s how you employed it. If you fighted against a Hornet and he wanted to get slow, you could do that but you had to be pretty damn good.’ 10 Percent true

According to the F-15E flight manual from 1993 the Strike Eagle is quite subsceptical to flight departure at high AOA due to high weight and lateral asymmetry contribution (due to the nature of air-2-ground load outs). Also CFTs are mentioned prominently often in the flight characteristics chapter in terms of ‘if CFTs are installed, the following is be observed:…’. Also the remarks for the out-of-control flight characteristics don’t sound too heartening. From that I cannot imagine that the USAF encouraged the Strike Eagle Drivers to go into fully blown air-to-air engagements beyond self defence cases with jettisoned weapons and fuel bags.