Aarnoman

Hmm, I'm unable to move with WASD/Arrow keys. Win 10 64 bit.

Works fine for me. Is "Use mouse" checked in your VR settings menu?

From what I have noticed in my testing is that shadows on (any setting including low) absolutely kills frames on SC. This is on a relatively decent system (GTX 1080, i7-9700k, SSD, Rift CV1). Interestingly, without shadows, I'm able to retain 45fps with ASW on the SC cold start without issues while maximising other settings including MSAA. However, as soon as shadows are on (even on low) performance drops to ~22 fps. This persists with almost all settings on low, including no SSAA and MSAA. I conclude that something is definetly not right with how shadows are processed on the SC. I am able to maintain 45 with ASW normally while over cities with more objects present at one time (according to ED fps output).

Curious, thanks for sharing hippo. I don't have a good explanation for why mine and wju's findings differ from yours; seems to work as intended and expected for you. Hopefully we will get more users data soon to figure out what is going on here.

It think it should be part of owning the Su-33 (and also part of FC3 as a result). As a SC owner I'm still baffled that it is included, I don't think its neccesary as it already offers plenty, and this essentially gatekeeps a nice single carrier behind a large price tag for people not interested in the US carrier experience.

Hippo, Sandman, please reference wju's graph. There is no difference regardless of mask size. 30fps drop with MSAA set to 4x (only change), and no difference in performance drop regardless of mask size. As I stated, mask size does not currently have a use. Please provide evidence to the contrary comparing performance between mask size at 0.1 and 1 if you think there is any difference in performance.

Good research. I hope this will also settle the debate on the North Arrow, which should be present in the Litening display.

Did you restart DCS after changing mask settings? This is required for changes to apply. Give it a try without supersampling to better visualise the change.

Version: 2.5.6.49314, Standalone Testing system used: Win 10 x64 GTX 1080 i7-9700k 16GB Ram DCS installed on SSD VR system: Oculus Rift CV1 Intended/Expected function: This version of DCS released the first iteration of MSAA mask size for VR. The stated function of this feature is to allow MSAA in the center of view, while leaving the peripheries free of AA. This serves the benefit of allowing for MSAA use in VR with a lower performance impact, as only the center of screen has to be antialised. Bug/Problem: Currently, the performance is identical regardless of mask size (0.1 compared with 1.0). The mask does appear to work, as with mask set to 0.1 only the center of the screen is antialised. However framerate remains identical with mask at 0.1 and 1.0 when the same mission is run. This leads me to conclude that the mask is applied after the MSAA pass. As a result, the mask does not serve a function, as there is no gain in performance with using it, but does reduce visual quality as the peripheries are not antialiased. Test mission used: Fa-18c ready on ramp caucasus Observed fps on this system: Average 34-38fps with MSAA turned on 4x. This remained at 34-38 fps with mask size set to 0.1, and mask size set to 1.0. The antialising was confirmed to be only in center of vision for 0.1, and full visual field when set to 1.0 - thus the mask is applied. When MSAA is set to 0x, performance increased to 45fps (with vertical sync on). Proposed solution: Mask should be applied prior to MSAA pass to allow for less resource use and thus performance improvement. Conclusion: The current implementation of MSAA mask for VR serves no purpose, as the whole frame is AA before mask application, leading to identical resource use (and performance drop) regardless of what it is set to. However, with VR mask set to a low value, visual quality is degraded (as peripheral vision is not antialised). Important note for replication - MSAA changes will not be applied until DCS is restarted.

Same issue here, clients connected to server not running in VR had no problem. I have uploaded logs on a different post here for this issue: https://forums.eagle.ru/showpost.php?p=4334256&postcount=15

I have been getting similar access violation errors. I have included 3 log zip's of seperate CTD's as a result in this post. There was no clear precipitating cause, with all happening mid-mission. I'm unsure if this is the same issue reported, but logs look similar so I will append them here. This may have already been resolved as per BN's post above. dcs.log-20200516-094050.zip dcs.log-20200516-092954.zip dcs.log-20200515-114222.zip

Thanks heaps, didn't know I was able to do that. Appreciate the quick answer too, I've already had plenty of fun with my friends in your mission. Thanks for sharing your mission with all of us :)

For a2g sites, is there any way to have the units spawned do a patrol/have specific layouts? I feel that this is the main drawback of the mission at the moment, all targets on the ground are static in one position.

Occurs in both Standalone and current version of OpenBeta (unmodified). Description: Texture fighting with model "Small_house_1b_area" Demonstration:

[Repost to F/A-18 bug forum, original post at https://forums.eagle.ru/showthread.php?t=261726 in wrong forum section sorry] There is currently a bug in OpenBeta 2.5.5.41962 (clean installation, no mods) where the F/A-18c fuel probe light passes through the canopy when extending. As can be seen in the following images, a light on the ground is visible when extending the fuel probe. This should not be able to be seen, as the canopy (hornet nose) should be blocking the path of the light, preventing it from lighting up the ground. A track file of this issue is attached to the post. This bug was originaly reported by feel2fer, who also provided the track file. DCS visual settings where on the high preset. System specifications: i7-9700k, GTX 1080, 16GB RAM.

There is currently a bug in OpenBeta 2.5.5.41962 (clean installation, no mods) where the F/A-18c fuel probe light passes through the canopy when extending. As can be seen in the following images, a light on the ground is visible when extending the fuel probe. This should not be able to be seen, as the canopy (hornet nose) should be blocking the path of the light, preventing it from lighting up the ground. A track file of this issue is attached to the post. This bug was originaly reported by feel2fer, who also provided the track file. DCS visual settings where on the high preset. System specifications: i7-9700k, GTX 1080, 16GB RAM. probe_light_on_ground.trk

/Copied from my post on ED discord on this issue: It makes zero sense for me why it would not be placable by a person editing a mission (if not purchased) as any other asset (i.e. any aircraft module) can be placed regardless of whether the mission creator owns the module or not. Users should absolutely have to own the SC DLC to use it, but the server host account or mission creator should not be required to own it to be able to include it in the mission, or run the dedicated server for it. It makes no sense and would likely see less servers utilise the super carrier, meaning less incentive for people to purchase it since their favourite server/mission may not even support it as a result. " This is coming from me after purchasing 3 copies of the SC (one for myself and two for friends). I really want it to be popular and succesful, but the current approach with locking it behind a paywall for mission creators seems like deliberately shooting yourself in the foot. To me ED should do what they can to support mission creators and server owners, as they are in large part the communities that bring in and nurture newcomers to DCS, and play an important part in the ecosystem that incentivises new purchases.

I personally think that (playing on the 104th as well) teamkilling is some issue. However, I have also found that most people are very apologetic, especially when they get taught how to make an IFF check in the Su-27. This is a simulator, and missiles kill, regardless of how they were fired from. I think it should stay that way.

This is a very awesome idea, +1 and some rep.

Very good suggestion, would love to see this aspect tweaked.

Agreed. I think even Falcon BMS has implemented this to some degree.

+1

Agreed, this needs to be removed or at least have an option to be turned off.

+2

+1