Rosebud47

It´s something wishful meanwhile, as I used to edit the default.luas now for years with all the inconviniences accompanied. Regarding my response I wouldn´t give an explanation too much space here as it is not my topic. Just let me mention, that this response is more the reflection of the attitude in the addressed comment, which me personally makes me stay away from discussions, even I would like to add something or participate in. The attitude of formulating a comment around provocation instead of dialogue related statement is quite present in any Internet forum. It´s easy to scare these, as the weakness in these commenting minds are obvious. My wish here is important for me and I don´t want to have a low-level communication connected to it. Well, I won´t change anyones attitude - people are what they are... maybe Internet forums are not for me and it´s sometime better to stay away from these. Thank you for your understanding and sum up my intention in better words, than I could do as a not native english speaking person.

Now that you´ve mentioned, lxsapper, I can´t do any other than totally agree with you, that it is defenitely not a realistic goal to configure your HOTAS as you wish it. And for sure, as you noted, it is actually more work to module developer setting up three binding methods for any key, than setting up three different binding methods for hundreds of keys. But the most embarassing of your comment is that you don´t understand the scope of it, which is why any medium intelligent person is able to redo the missing configuration options by editing the default.lua for exactly the attitude the switches need to have, what surely is the intention of the developer, right? Sorry man, but you better get back commenting in the "we-want-a-Tic-Tac-Toe-UFO-in-DCS" thread or any other kindergarden discussion.

Yeah, I was actually thinking of the same options for every key function. What we need is a general overhaul of the control setup. Looking into each key/function to decide how it might be mapped for a hardware switch, is much more work for the developer, than the invention of a general standardized option menu for every key/function, to enable the user to customize the function for his individual hardware and concept of mapping. Furthermore a general option menu should work for every module the same. If someone at ED do care for it and developes a working algorythm for it, then it could be hand over to any 3rd party developer as a template, where the 3rd party developer only need to fill in the usable functions of its own new module and don´t need to spend time and work into inventing an own concept for mapping his module. Just read through the forum: there are everywhere issues with the key mapping for most of the modules. And there will be many more modules coming, following the current announcement. This will escalate the messy situation with configuartion setup, we are currently facing. There need to be a standard for key mapping, which satisfies all the different hardware and simpit configuration out there. It´s not that someone made a mistake, it´s about paying attention to the development of hardware configuration on the user side. With recent update, there was an improvement with the configuration setup, but there is still space for some more significant improvement. Adding an option menu to each function the same, where each user could choose, if a function should be bind as a) a toggle key/button b) a switch key with up/ down c) a switch key with down/up and d) analogue axes is less work in the development, than looking into each key separately. With these four options for every key, every user is free to customize the functions for his individual hardware configuration. You´re surely right saying it doesn´t make sense to have an option for an analogue axes for an obvious switch key, like gear up/down, but people are not stupid and won´t map this option unless one decides, that it make sense for his own configuration by having mapped on to analogue axes. The point is, that the function need to be customizable by the user and not predefined by the developer, what is neither satisfying for the user, nor for the developer. Another interesting example might be the cockpit lighting for the F-14 Tomcat, which is in the cockpit done by a up/down function in 9 steps - for the user it would be much better to have this mapped on analogue axes, if he got an analogue hardware switch and there were an option to customize the function within the control setup. Also the developer are forced to push out the modules as fast as possible, but the experience shows, that the control setup at this stage in module release is always neglected and the graphical issues always got priority before there is even time for a developer to take care of the control setup. In my opinion a proper control setup with the freedom for customization for individual hardware has got a much more bigger impact on the DCS experience, than having four types of clouds for example. Another argument to bring standard customizable functions to the control setup is the increased development of additional hardware on the market for flight sims, like the new VKB Thrust controller, new button boxes, and more of this. Everything grows, DCS modules, supporting flight sim hardware and user demands. To face this growing development there need to be some advanced standards for the growing complexity.

Please set an option in controls / key mapping to define each function as a toggle key, up and down switch and analogue axes for every module. It´s a pretty mess, what we are doing so far with external tools, .lua editing and what not, to map the keys for our simpits. In addition to the three types of buttons and switches mentioned above, there would be also a type of switch with an up-, center- and down-position of great advantage to map our simpits properly. Another pain in the *** beside the absence of these control options is, that with every DCS update or patch, we are forced to redo all the adjustments to our individual hardware configuration for every module! Love the progress DCS is taking with every update - this is a wish to bring to your attention.

The lighting in the new Black Shark cockpit is fantastic! The warm sunlight reflections on the material is great. And it got even better, when turning on the night lights in the Black Shark: simply wow!, how much depth there is in detail. Hope ED will work on and patch the key bindings and mapping, like more mapping to axes for analogue controls and more options to switches for the usual HOTAS systems. It´s a tiny quality of life feature to provide a wide range of mapping possibilities, but hardly missed, when there no more options to bind the functions on to a variety of hardware. Thanks ED for this free cockpit update - love it!

Einfach in DCS unter Menüpunkt "GUI Layer" einen button für VR neu zentrieren mappen. Um die Kopfposition im VR Cockpit besser zu definieren, kann man sich z.B. etwas vorlehnen, dann zentrieren, dann wieder zurücklehnen. Die dann etwas vorgeschobene Kopfposition bleibt im VR Cockpit dann erhalten ( das geht natürlich auch mit der Höhe der Kopfposition, wenn man sich etwas aufrichtet beim Zentrieren ).

Danke, das spart viel Zeit und Nerven ... Bin gestern Abend noch über das Tool ´Joystick Gremlin´ gestolpert - damit könnte es gehen.

Hallo, weiß jemand, ob die TARGET Software von Thrustmaster auch für einen Warthog Stick funktioniert, der auf einer VPC T-50 CM2 base montiert ist? Oder alternativ gefragt: kann ich mit der VPC Software eine Keyboard Taste auf einen Stick button legen, auch wenn´s ein Warthog Stick ist?

The rainbow effect some people perceive with DLP projectors truly is an individual thing - it depends on individual inertia of the eye ( actually we see in waves not FPS-like frequencies ). A DLP projector uses another technique than LCD projectors, so the rainbow effect only appears for some with DLP projectors.

I don´t think, that you´ve increased the render resolution or image quality by editing maxRecommendedResolution in the steamvr config file.

Hi Dave, updating to the latest Pitool version is recommandable as well updating the firmware of your headset through the newest Pitool version. Forget about the nonsense people in the internet claiming that a Pitool version bricked the headset. Pitool could be in some cases unstable regarding certain settings in Pitool. It may help, in case you encounter some unstable setting issues, to redo the firmware update of your headset. Enlarging the maxRecommendedResolution in steamVR is not absolutely needed - it simply enlarges the scale in SteamVR, where you could set a custom resolution. What counts is the resolution you actually have set in SteamVR. A resolution beyond 4096 would be very much, maybe too demanding for DCS in anyway, so a resolution below 4096 is more recommandable. There a three options to level Supersampling: a) Pitool b) SteamVR c) DCS pixel density It´s up to you, which path you´re following, there a different opinions which rendering path is preferable respectively more performant than another. Downsampling with DCS PD -1.5 and then upsampling with Pitool or SteamVR is not recommandable as it induces some workload in the rendering process accompanied with some loss of image information/quality to get finally the same resolution by simply supersampling with one of the three render pathes, while keeping the other two render pathes at default. Me personally use DCS PD to supersample ( PD 1.1 or 1.2 ) and keep the other two close to default ( Pitool Quality 1.0, SteamVR close to native horizotnal resolution ) The more you upscale the less blurry the image gets in the distant view, but it´s a very performance demanding process. Also the panels of the P5 XR are OLED, as far as I know, which means the effect of blurryness and screendoor might be a bit more present than in the LCD panel versions of the P5K. For the P5K LCD using 2 x MSAA in DCS reduces the aliasing effects significantly. If you got the impression of strong aliasing it would be recommandable to find a balance in performance between DCS MSAA and supersampling level of the different render pathes. Here around is a thread titled ´Nvidia inspector settings´ or something like this, which leads to some tips for fine tuning image quality. To improve the comfort of the headset the Deluxe Audio Strap from HTC could be used for Pimax headset with 3D printed adapters - a very good solution to replace the standard rubber band of the current Pimax headsets.

Not arguing around ´mine is the best´, I would think of the Rift S as a solid and good headset with respect to the comments getting here around. There are no such complaints about having issues, like with other headsets. To get into VR or just having an easy time - it is a good device of choice. Also the image quality step from switching from OLED panels of the old CV1 to a bit higher resolution LCD panels with Rift S must be significantly. The advantage of the lower resolution panels with regard to some standard of 1600 x 1440 with regular VR headsets, surely results in less demanding performance to run the Rift S on various systems with various graphical setting. But it can´t denied, that higher resolutions result in better image quality, what is the main value for the quality of TVs, PC flatscreens, smartphone displays and cameras of any kind. Anyway, Oculus seems to have reached a proper and rocksolid VR headset, maybe not so much for VR enthusiast :D, but for the time being. Beside Samsung´s Odyssey+, I would highly recommend the Rift S to enter VR or enjoy VR without any issues, but from there, next step in price and quality surely is Valve´s Index and so on.

@Hammer yes, I could see the difference of the sweetspot in comparison to the video of MRTV. I think, VRengineers really perfectionized the lenses of their VR headset. The lenses didn´t so far got that much attention, needed for better results in the development of HMDs. It seems to be also much more challenging producing good lenses for wide FOV headsets, than for standard FOVs. The fresnel lenses in most/nearly all VR headsets are very much the same. Valve made an approach to improve the lens tech for the Index with some respectable results, i would say. I guess the lenses of the Pimax are the reason, why there has to be a masked area in the FOV of the Pimax headset, as I would assume that a distortion made by the Pimax lenses need to be covered/masked. The XTAL lenses seem to be such perfect, that they dont need to mask and bring the full potential and resolution of their displays to the eye. Also the XTAL lenses might be the reason for the high price of the device ( beside some additional tech ). Producing high quality lenses is in first step very cost intensive, as there has to be first created and designed a mold to fill with molten glass. I guess one mold only will be approx 10.000,- and god knows how much molds and lens prototypes they had to produce to come to the perfect shape of lens for their design. But Prague is very famous for its traditional glass molting industry, I would further guess, that at least one of the VRengineers team is close connected to this industrie to get the quality of lenses they use. So taking into account, that beside the huge compatibility of tracking solutions, while havin in focus commercial customers for their device, like VR theme parks or public VR experiences, VRengineers seem to set the price such high to get a return of their investment for producing the lenses quick. With this point of view it is not very optimistic for the future of VRengineers. Also they surely will have difficulties to get into a consumer mass market, as the price to get into this, must be below 2.000,- at least, what is a huge step from 5.000,- $ per unit. Surely the price for the lenses could get lowered, when they are going to produce numbers up and beyond 100.000 units, but these numbers need be sold in the mass market for rentability and I got doubts, that they could get into mass consumer market with a price tag over 2.000,- per unit. Maybe if the radically reduce the features of the XTAL, like only having Lighthouse tracking and hardware IPD setting, no Foveated rendering, but when they got their product on a consumer level tech, the big company competitors might have a better product at lower costs at this point. Really difficult for XTAL as they started with a high end product at exorbitant costs and selling prices. I do hope there tech will survive and being developed by big company investors maybe as they really achieved something no one else has so far. @Aurelius Did you ever tested Playstation VR in the lab? Maybe it´s a new winner for your personal preferences.

Just realized, that I had set "Texture filtring Negative LOD Bias" to "clamp" instead "allow", what seems to be resulted in lots of shimmering again. With set to "allow" as you recommend shimmering is again so much reduced. Now I need to fine tune sharpness ... As far as I understood, SSAA in DCS is practically the same as PD, whereas SSAA is for the monitor output and PD for the VR headset output. @dburne latest research of transcriptions revealed, that these words of Confucius are misinterpreted. The correct translation says: "He, the wise man who goes along the green hills down to the water, has always tuned his fishing pole to catch the fish for the emperors men."

@Chapa Yeah, me too would say, that the graphical fidelity received depends also on the module. I´m gladly looking forward for the reworkd MiG21 cockpit, what should be more optimized for VR than the current one. The new F-16 looks a bit more washed out in VR than other cockpits, but the F-16 I would consider as a work in progress also in terms VR graphical optimization. I think the Tomcat could be considered as a standard in it´s graphical optimization and performancewise. Beside this, the headset in use also makes some differences, like the P5K+ I´m using tend to shimmer more than others I think. FXAA should work in VR, it is cheap in performance consuming, but makes the whole image more blurry, what would counteract any approach to sharpen the image. I wouldn´t use FXAA. Now you´ve made me a bit unsettled regarding the use of AA with nvidia inspector. But I´m pretty sure, that the count of steps at thin edge line was significantly increased due to switchting from 2xAA in nvidia inspector to 16xAA. Anyway the steps were still visible and shimmering and not flatted out without shimmering. First time I tried some settings adviced in this thread the image was really good in the MiG cockpit. I´ll try to find back these settings.

@Chapa just tried your settings and what I could say for sure is, that MSAA2 in DCS really makes the image a nuance less sharp and blurry, while with setting MSAA off, the textures lok a nuance sharper and the image a bit clearer. At the moment I see shimmering quite a lot, but recently I flew the F-16, which is more shimmer free and more optimized for VR than the MiG, which I flew today. Maybe there´s also some influence of ´selective perception´ at the moment, what causes your eyes to focus on what the mind expects to see. :huh: In nvidia inspector there´s the option Antialiasing mode, which offers much more modes, than the regular nvidia driver settings. Just tested two modes only and the effect could be already observed at the edges of the DCS mains screen in VR. Will try more of these options as there is a lot of Antialiasing variants. The good thing is, that the nvidia settings the image quality could be enhanced, while having performance much more in balance as with DCS PD or MSAA.

Today´s setting in SteamVR is 2724 x 2324 Pitool: @90Hz, Parallel mode, normal FOV. I´ve reduced Sparse Grid Supersampling to 2x, set Nvidia Anisotropic Filter to 16x override application in nvidia driver. In DCS set PD to 1.0 (!) and disabled Anisotropic filtering...only left MSAA 2x in DCS In result it looks really good and is quite performant so far. Shimmering is mostly gone, what is really a small wonder. Before using nvididas image sharpening and the additional settings we´re talking about in this thread, DCS was close to a shimmering mess when set PD in DCS to 1.0, but now it´s better than before with PD in DCS at 1.3 or 1.4. That´s surely no placebo.

@USAFMTL nice atmospheric lighting at your pit. Do you have anymore oscillation now? I have taken a wooden plate, which fills out the entire inner frame on the ground, just for a nice look and feel. But on the other hand, with your construction, you could still move the seat back and forth, what I can´t anymore :-))). :thumbup:

Always like to chat or discuss with you, Harlikwin, but in this particular discussion the problem does not come from ED, as anyone could think by themselve. ED developers are surely aware of everything you expect from this feature. There was already a post by Nineline or Chizh about the implementation of VOIP today. Discussing about how much expectations might differentiate from one to another doesn´t make so much sense. Surely I would expect the same as you, but don´t consist that my expectations need to be fullfilled right now in this case, that´s not how grown ups react. The VOIP feature gave me a big smile today ( more because of how it works with my sound setup ) - happy about it and already thought of joining more often multiplayer server, because it makes communication with other people online much more easier in the first place. Hope it will not end up with people belching into their microphones :megalol: Anyway, SRS still could be used. It´s not taken away from anyone. But already found a bug with it. Just took a ride in the Mig21 and the sound of the landing gear retracting came over the headphones instead the environmental sound system. Now, that is a reason to complain :smilewink:

PTT could be set in the ´GUI layer´ section.

Me got your point, Tippis. But why being so upset and summoning the bad ghosts of past early access discussion with some fear in mind it might never get to the point where it should be? ED also clearly stated, that this is the first step and approach to implement a basic VOIP system. It was also stated clearly how VOIP will be developed and at this point it does not need to be clearly stated, that every new feature coming to DCS is a first approach for further development. Give it some time, you´re just a bit too early to damnate a feature, which is just some hours ago presented in the very earliest access of its development.

Yeah, it does make sense if you´re using a stereo or surround system in addition to the headphones. Luckily my wife sleeps in the next floor and have the doors closed, when I have to put the afterburner of the MiG21 on.

What I like very much with SRS is, that it enables you to have the radio communication to set up on the headphone driver and the DCS sound on to the stereo speaker/subwoofer driver. But that meant, that all DCS radio sounds, like ATC were directed to the stereo speaker. Now you could add in DCS sound a separated driver for your headphones, but keep the engine sound, environmental sound, cockpit sounds on the speaker system.

Have to take a round with the Tomcat tonight to hear if Jester now also speaks through the headphones. :)

If you want to get the full Index set, you´re also above 1.000,- The full Vive Pro set is also above 1.000,- I would think, that Pimax only sets up their prices into the market. They got some real unique selling points compared to the competitors and they know, what these selling points are worth. I´m really happy with the great offerings they made for the backers...didn´t count with that. The more interesting thing is, that the competitors don´t make such huge steps with their VR headsets. The Rift S is slightly better as the CV1 with some different features ( like tracking ) and some less features. The Vive cosmos was really disappointing as it does not make a next step in the evolution of VR headsets. HP simply put better diplays in a standard VR headset frame to get a unique selling point. To see, that independent start ups could do the next steps in tech evolution should bring up some question, why multi billion dollar companies don´t. As having said, I hope I don´t need to buy another new VR headset for the next 5 years.