Daikan

Curiously, has this gotten any better since the 5.1 update?

Metal is not supported - that's been stated very clearly by the author and publisher. See the official product page and search for "metal": https://www.x-aviation.com/catalog/product_info.php/skymaxx-pro-p-198

There is no refund for downloads like SMP. https://www.x-aviation.com/catalog/refund_policy.php

I don't have v5 (yet) but using my Oculus CV1 and SMP v4 I cannot reproduce any of the issues with ground fog you are describing. But maybe you are using the word "fog" wrongly. FYI: "fog" is what X-Plane only applies BELOW the bottom cloud layer and is controlled by X-Plane's "visibility" setting i.e. without at last one cloud layer there will be no fog at all. Additionally, X-Plane uses a "haze" model which is still somewhat influenced by the "visibility" value but has no significant impact on ground visibility under ~10km (e.g. if you set visibility to the absolute minimum possible and no cloud layers you will still be able to see the ground from miles away). AFAIK the way "fog" and "haze" are represented is not changed by SMP at all (neither in v4 nor in v5). However, I can somewhat relate to the described issues in v4 when inside or above the lowest cloud layer, so IMO what you are describing is actually due to differences in representation of the cloud billboards for the left/right eye. I assume these artifacts will be gone when using volumetric clouds in v5 - although seemingly at the cost of a whole new set of issues (and the reason why I'm still holding off and watching this topic with interest...).

IMO this is a long known X-Plane limitation / bug. Here's a video showing what happens using vanilla X-Plane 11.51 and weather manually set to RVR 1200m and overcast cumulus bottoms at 2000ft MSL while transitioning from the ground at 1200ft MSL into the cloud layer (looking straight down in this case): ec135 - 2021-01-24 21.51.01_Trim.mp4 Here's the same movement using a different perspective (looking slightly downward): ec135 - 2021-01-24 22.12.19_Trim.mp4 You can see how visibility temporarily "snaps" from foggy to a complete whiteout followed by a sudden change to perfect ground visibility shortly before entering the actual cloud layer. This example is more drastic due to the very low visibility chosen but I think it's the same effect.

Too bad, but okay. What about the file Silverlining.override? It seems as if it can be used to override any defaults in Silverlining.config, can you confirm? If so, this might make it a little easier for me to re-apply my tweaks in the future....

I always found the stars in the night sky to be way too bright in VR. So my solution was to tweak .\Resources\plugins\SilverLining\resources\Silverlining.config as follows: starlight-scale = 0.0 minimum-star-magnitude = 10000 star-maximum-light-pollution = 0.001 minimum-star-glare-magnitude = 0.0 star-point-size = 0.0 star-magnitude-adjustment = 1000 This however gets reverted with every update and so I have to go back each time and re-apply my changes - which kinda sucks. Is there a way to make these tweaks permanent so they survive future updates?

I'm getting regular stutters at 3-second intervals using SMP 4.9.3 and XP 11.50b10 under Vulkan. They disappear after I disable SMP via plugin admin. Using the microprofiler and comparing frames I could determine they are caused by ~7ms spikes in the "XPDDoDrawingHook" timer in the main thread. System: Win10, i5 8600K, 32GB, GTX 1060 6GB

Love the new VR support introduced with 4.7 - good job! My only gripe are the noticeable cloud billboard "rotation" artifacts when turning my head. They are most noticeable when looking at cloud puffs directly above or below the current viewpoint location. Hopefully that gets fixed.

Just a note regarding the promotional email I received about the 1.1. update. There it says: In fact, this was not true for me (running the SMP 4.7 installer did not touch my RWC installation and it was left at 1.0). I had to manually re-download RWC in order to get 1.1.

I just wanted to chime to try to give VR support some more weight. I took the VR plunge as soon as XP11.20vr1 was out and there is really no way of going back to non-VR for me. Realizing that SMP4 was not VR-compatible was disappointing although not totally surprising. However, reading the comments in this thread had me worried a bit regarding the official stance towards VR. I realize it's very early on and it might be a "niche" now but IMO it is foreseeable that the general adoption in the flightsim sector will continue to grow substantially - once you've experienced it it is hard to believe otherwise, especially if you're into flightsimming mainly for leisure and fun. Just as an indicator: There have been 722 posts in the newly created topic VR in X-Plane 11 alone on x-plane.org since January 2nd...

No biggie but it seems the reflections of the sun on water surface are misaligned... SMP 4.5 XP10.51r2 Hosek-Wilkie sky model Enable cloud reflections on water: Off

I have exactly the same issue and I was able to track this down to Rendering settings -> Shadow detail -> global (low). If I set it to 3d on aircraft my FPS are back to normal. SMP 2.0 does not suffer from this problem (just tested it using same setting and plugins). In this state SMP 3.0 is almost useless for me. My system specs: EDIT: Funny enough, after setting the shadows to global (medium) my FPS increased almost back to normal! Even funnier: After I set it back to global (low) my FPS were back where they used to be... This makes no sense whatsoever - but it fixed the problem in my case. Could be that all it takes is to change the shadow setting once in order to fix the problem.

I take it from the release notes that there is no support for AI and/or multiplayer aircraft (e.g. they still won't emit any sound). Can you confirm?

Tony, I'm not sure but I think I might have stumbled over a problem with objects/road.net which gets included with the generated scenery (this is with the public 0.7.2 beta) IMO line 61 is wrong: Currently it is: ROAD_DRAPED 3 250 0.10 0.00But it should be: ROAD_DRAPED 3 256 0.10 0.00Can you confirm? Also, I wonder why a separate (updated) road.net is included with the generated scenery when instead there already is a network definition which is part of the world models library (virtual path "network/w2xp.net")... EDIT: I think there are also problems with the way the powerline pylon/tower objects are currently referenced in road.net: I seem to recall that the "OBJECT_GRADED VERT" directive does not work with virtual (library) paths and therefore the objects need to be referenced relative to the location where road.net resides... I was wrong: Virtual paths for providing an asset reference in "OBJECT_GRADED VERT" work just fine However, there seems to be a problem with the vector definition of the second vector rule in the current config.xml which causes it not to render (changing the ROAD_DRAPED directive as suggested above didn't seem to help)... I ended up fixing this by using the standard vector definition "220" as provided by the built-in roads.net (e.g. lib/g10/roads.net).