Rosebud47

100% Renderauflösung in SteamVR für die Reverb G2 ist viel zu hoch eingestellt. Ich vermute mal, dass sich die 100% in SteamVR auf die Valve Index Index beziehen, die mit einer nativen Auflösung von 1600 x 1200 weit unter der nativen Auflösung der Reverb G2 mit 2160 x 2160 Pixel liegt. Das ist auch die wesentliche Einstellung, die die Performance beeinflusst. Mit der 3080TI steht die Renderauflösung in SteamVR bei mir bei 62% ( 2496 x 2440 pixel ) mit der Reverb G2 - das ist ruckelfrei und ohne Ghosting bei meinem Rechner ( das Skalieren von der nativen 2160 x 2160 Auflösung der Reverb zu 2496 x 2440 dient vor allem der Kantenglättung und einem etwas schärferes Bild ). Vorher mit der 2080Ti hatte ich die SteamVR Renderauflösung auf 56% oder 58%, um ruckelfrei zu spielen. Bewegungsglättung in SteamVR ist auch grundsätzlich an - das macht die Kopfbewegung im Cockpit flüssiger, lässt allerdings die Armaturen während der Kopfbewegung etwas verwaschener aussehen. Wenn der Kopf/Blick wieder fixiert ist, ist es aber wieder scharf. In SteamVR gibt es die Renderauflösung einmal unter ALLGEMEIN und einmal unter VIDEO. Wenn man nur DCS in VR spielt, kann man die VIDEO Einstellung ignorieren und nur über ALLGEMEIN die Renderauflösung skalieren. Die Einstellung unter Video dient dazu, über Spieleprofile für verschiedenen Spielen unterschiedliche Renderauflösungen zu speichern. IN DCS sollte PD und Supersampling am Besten unberührt lassen - Das Bild wird ja schon über SteamVR skaliert, gesampled oder hochgerechnet. Anonsten habe ich in DCS AntiAliasing immer auf 2x, das hilft auch gegen das Kantenflimmern und drückt die Performance nicht so sehr wie Supersampling. Der Rest in DCS ist Feintuning und Geschmackssache... hängt auch von der verwendeten Grafikkarte, VRAM und CPU ab, wie weit man da gehen kann.

Das bedeutet, dass ein Konflikt in der Tastenzuweisung vorliegt. Schau mal im Ordner C:/*deinName*/gespeicherte Spiele/DCS.openbeta/config/input/*Modul Name*/Joystick/... Wenn es in dem Ordner mehrere Dateien für ein und denselben Joystick gibt, würde ich die älteren Dateien löschen und nur die jüngste Datei behalten. Ist jetzt keine Universal-Lösung, aber vielleicht hilft es, die Ausrufungszeichen weg zu bekommen. Eine Ursache für den Konflikt könnte sein, dass der Joystick irgendwann von einem USB Port in einen anderen gesteckt wurde und DCS eine neue device-ID vergeben hat und so eine neue Config-Datei für den Joystick angelegt wurde, die jetzt irgendwo in der Tastenzuweisung mit der alten Joystick Datei kollidiert.

Punk Rock ( USA ) Punk Rock ( Malaysia ) Punk Rock ( Germany ) Punk Rock ( UK ... well, you could either love or hate him, but finally his entire body has become a piece of art )

FidelityFX Super Resolution looks like to be a far better solution qualitywise and in particular performancewise than ´VR PD´ at DCS setting we got for for VR or setting VR render resolution per eye within SteamVR. It reads like FidelityFX Resolution could make both, VR PD in DCS and SteamVR render resolution obsolete for getting best results in picture quality and performance. So yes, if ED Devs could implement: +1 to go for!

The only working solution for me is, switching the DCS window on the desktop into full screen mode by clicking ALT + Enter.

Could we have completely separated keybindings for the pilot and for the gunner? If it stays mixed up, the same key for the gunner and the pilot for the same function could not be bind on to the same key on to our hardware. I understood, that there is an additional option to bind in general, beside two options for each the gunner and the pilot, but beside it is very confusing, it also didn´t work in some cases and creates conflict. A completely separated keyset like in the F-14 for pilot and RIO is a much better solution to avoid conflicts, more clear and simply makes life easier. Also, more binding abstractions are needed, like a toggle switch for each Autopilot-mode and ´up/else down´ positions for HOTAS, but we know it´s EA and keybindings option are as usual and unfortunately very late in development schedule. But it is also fact, that keybindings are needed from the start up for every module to control the module no matter which state in development or early access it is. It´s not a big deal with regard to development time and effort. Finally, thank you for this fantastic Hind - Simulator! The graphical fidelity and flight model is unprecedented!

I go swimming. Enjoy summertime, boys!

With Black Shark 3 there is an overhaul planned for the Shark´s 30mm cannon. So far it was mentioned the overhaul in regard to the algorythm of the cannon beside the graphical improvement. I would assume, that we will also getting an improved sound as well.

in the mood for Mi-24

Done! Better than doing nothing in hope that it could be an option for our developer to improve performance.

At the bottom of the mixed reality portal window, there´s a button/symbol like "play/pause" at a Youtube video. Just klick it and the screen in the windows goes off. I´m not sure, because of my lousy memory, but I think there´s an option too in the SteamVR or SteamVR for wmr to untick for not starting in the cliff house, but I need to search and find it again by myself to be able to point to. Was some time ago, when I configured, but since then the screen in the WMR Portal Window stays off and only the mirrored screen of DCS appears on the desktop.

I only execute DCS from desktop. During the loading process of DCS the WMR windows pops up automatically and the headset gets active, then I put it on and am in the DCS main menu screen with MiG29 in the hangar. SteamVR and Windows mixed Reality for SteamVR are loading in the background but don´t show up with a window or icon in the task bar. It´s super easy. Also Cliff house does not show up as the WMR Window could be set with no image or no Cliff House to render. But really hope OpenXR will make life easier, as I would think a direct link to the API without interconnecting tools might result in better performance.

Oh, I would say, the 3rd parties are in deep relationship with ED´s work. But I got your point, leading to some often heard discussions, in which people spread out ´knowledge´ about how ED manages human resources inside the company - I won´t follow discussions in this direction, but would think, that to every project, there is at least one lead project manager responsible. My point is, that the delay in releasing awaited modules, might be related to ED´s work in the background, like new cloud systems with 2.7 or Vulkan implementation, handling of missiles in the simulation or something else in the background simulation, which may impact the work of the project managers of one module and/or the 3rd party developer´s modules. There´s always so much going on in the background simulation. I´m more in the trust-and-patience-team, when looking at the long roadmap ED has got and the overall size of the DCS World project. I would say, let them focus on their priorities, for example bringing the Hornet out of Early Access ( a lot of people are waiting for this step for a long time ), fixing the clouds, etc. etc. and then get focus on the next point on the to-do list. I´m pretty sure the Mossie will be released in Early Access before the AH64. The answer to this thread would be simply: no.

Frankly, I can´t see any truth in the assumption, that the Mossie is hold back because ED commented in the last newsletter around the AH64, that they want to focus on early access for the Apache. This is how rumors start, simply on discussing assumptions out of nowhere. We already do know, that the Mossie is ready, but gets an upgrade of the outside textures. Somewhere Bignewy mentioned, that the texture upgrade makes good progress. What I wonder about is, that so far none of the expected modules, which should be ready meanwhile, is released yet. Well, the Hind surely will be released within next two weeks ( realistic estimation ). But beside the Mossie, what about the Kiowa or the F4U Corsair? Following the development, they already should have been realeased, but the news about these got very quiet now for some time. I wonder if there´s something else going on in the background, regarding extra work need to be done for a proper implementation into 2.7 and the new cloud system. The Mossie is an instant buy for me, but more because it is a two prop engine fighter bomber and much more interesting to experience for me, instead more of the same single seated, single prop fighters. Well, any additon to WW2 scenario is appreciated for sure, but there´s a special interest in the Mossie, I would say.

... after Italian Music exploitation and good ol´ 70´s ( love it! ), there is some need for Berlin Rave vibes ... Bonus Track for Xilon_X ( UFOs included :))) )

that´s interesting, that you made different experience regarding the noise. Better trust your experience than my holey memory in what I´ve read on the internet. Hace you tried to put rubber or kind of absorbing material to put between the mounting of the bases and solid parts like walls or furniture. Strangely mine had sometimes gone louder and sometimes less noisy. Meanwhile I´ve sold them and want to stick with inside-out tracking, as I only use VR for DCS and MSFS.

The base station 2.0 has got improved mechanics inside; less moving parts, as far as I remember. The base station 1.0 make a sonorous/vibrant sound which could be annoying, when you´re in a silent room. This vibrant sound of the base 1.0 could get louder, when it translates on to furniture, or elsewhere they are positioned and not rocksolid mounted. I never had the base 2.0 for a direct self-experienced comparison, but have read, the base 2.0 are more improved in this regard. If I had to buy new, I would invest that extra to get the newer base station 2.0. Also to be more futureproof.

definitely not with eaglecash867. The Alienware M15 R5 does not have Display Port connection.

Ah yeah, you´re right Eugel, just had a look and it´s connected to USB-C and DisplayPort... anyway something to figure out for deckard.

Maybe just check, if the new Laptop got USB-C connection. The G2 is natively connected to USB-C, but there is also an adaptater from HP coming with the headset. I´m just not sure, if it is a HDMI or display Port adapter. In anyway there should be good adapter e.g. from Microsoft available to connect from USB-C ( HP Reverb ) to HDMI 2.1. If you need to buy an adapter separately, make sure it is recommended for HDMI 2.1 as there are differences within the adapters on the market.

For me, running a G2 at the moment ( and being happy with it ), the upgrade to a VP2, is too expensive. But the different output resolution makes the VP2 very unique and it could bring some really good advantages. So far the output resolution of every VR headset is fixed to the displays resolution. The reason for that, I believe, is that the resolution all the headsets provide, is on the edge of screendoor effects or below. Now with displays of a resolution 2160 x 2160 per eye (G2) or 2448 x 2448 per eye ( VivePro2 ) this edge of a noticable screendoor effect is overcome. Theoretically - practice tests need to show, if the theory works - with the Vive Pro 2 you could run it a lower render resolution with better performance and without any screendoor effect. Maybe at lower resolution and less to need rendered pixel, there could be add all the nice effects DCS provides and maybe got a better picture and better performance as in the high resolution of 2448 x 2448 and bad perfromance because of the high render pixel count. The point is a non-existent screendoor effect and shimmering effects with the lower output resolution on the high res. displays. No other VR headset provided this option before. Well, practice has to tell how this works. I´m pretty sure that the output resultion options soon will be integrated into SteamVR, so the Vive Software would not be needed in future to adjust the headset. HTC and Valve were always in close cooperation. Regarding OpenXR in DCS, I would think it is a waste of time to implement OpenXR into the current DCS graphic API, as OpenXR is fully integrated in Vulkan. Once DCS switches to Vulkan, OpenXR will be the new API and every headset will have a native support in DCS from this point on.

I like the pilot bodies of the F/A-18 and the F-5 the most. These two do fit perfectly by the dimensions in the cockpits to give some organic impression of yourself controlling the aircraft. Interestingly the new pilot body of the Harrier is much more detailed, than the two mentioned above, but looks very much out of place in the Harrier, beside its dimensions gives the impression of 12 year old in the cockpit. Maybe an overly detailed pilot model result in an uncanny valley effect in VR, while the more simple graphics, but right dimensions and movement of the model provides the right feeling in VR. There are a lot of really genius graphic artists at ED and 3rd Parties - creating a simple pilot body isn´t a big task for them, but adds a big effect for VR. While looking forward for the Hind, Apache and some of the other announced new modules, I already fear them feeling incomplete for years without a pilot body, just because the developers don´t have attention to it.

That´s a diplomatic point of view. Got the button mapped by default to switch the pilot body on/off, so it could be switched on/off quickly, when it is in the way. It just reminds me of Wags latest video for the upcoming Hind, where even the pilot seat could be switched on/off, when it is in the way, but I guess no one would leave the pilot seat switched off. Surely we got inevitably used to fly without a pilot body, especially in the early access modules, but meanwhile it bothers me, if there is no pilot body in VR available at all - it should be included by standard.