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.

Do you really think those properties can't be faked by an attacker?

@Cameron I'm not saying the email was a (malicious) phishing attempt - only that it has many aspects classifying it as such and which could have been avoided. Also, maybe you can answer these questions: Why not distributing a direct dowload link pointing to x-aviation.com without having to go through an unrelated domain? Why does an X-Plane plugin updater/installer have to run with admin privileges? Why can't the .exe be packaged in a trusted fashion i.e. using an executable that is signed with a trusted certificate or at least shipped alongside with a published MD5 hash on x-aviation.com or x-pilot.com that we can check ourselves? Thanks.

So like probably many users I received that email a few days ago claiming to be from "orders@x-aviation.com" via some mailing list asking me to update my Gizmo Beta version because it's about to expire.... If you're like me and sensitive to phishing attempts in your inbox then that email has all ingredients that would usually make me toss it into the spam folder right away: According to the SMTP headers the email was sent by a mail host mail93.atl51.rsgsv.net The "List-Unsubscribe" header contained an URL pointing to a domain ending in us1.list-manage.com and a mailto: hyperlink ending in "@mailin.mcsv.net?subject=unsubscribe" The direct download link for the installer points to a top-level domain ending in us1.list-manage.com The downloaded installer is an untrusted Windows executable that requests privilege escalation upon execution Nowhere in there is any trustworthy reference to domain "x-aviation.com" to be found except in the "Sender" and "Reply-to" headers - which is useless as they can be both faked easily. And why an X-Plane plugin installer should require admin privileges is completely beyond me... To be fair, the download link contained in the email will redirect to https://www.x-aviation.com/downloads/Gizmo_Updater.zip (+ 2 URL parameters that are presumably for user tracking), but that will become only apparent after clicking on the link from us1.list-manage.com.... I would have expected a more professional distribution than this...

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).

Hi Tony, Thanks for your update regarding the status of W2XP, very interesting approach, indeed! It sure looks nice and it makes a lot of sense performance-wise and is more aligned with X-Plane's fundamental concept of a "plausible" scenery (as opposed to 100% realistic). However, I'm one of those guys that will probably sorely miss the unprecedented level of realism based on building-footprint accuracy in the present version. Overall, I think it provides a better level of "recognition" with reality even though the details can be way off compared to the real thing at times... For VFR and helicopter flying I think it's more important to have buildings placed as realistically as possible in terms of their footprint and size whereas the type, color and regional properties are somewhat secondary... Perhaps going back all the way to a pure facade-based approach (like with OSM2XP) might provide better results in the long run... I would be interested to know if you see that both concepts will be able to coexist and if so, how? I mean, one possible scenario would be, that your new approach would kick-in automatically either in those areas with poor OSM building-level coverage (as with today's smart exclusions) or at the opposite end of the spectrum, e.g. where OSM is so detailed over big areas that it will ultimately kill performance (i.e. big urban areas)... In any case, I'm really happy to know that you're still committed to the project and haven't given up - keep it up please!

Will this provide sounds of other aircraft than just the user's?

IMHO clearly a case of bad/unfortunate OSM tagging. As there seems to be no clear best practice in order to tag single power poles of an electrified railway line your best bet would be NOT to tag the catenary masts and instead use the additional tag electrified=contact_line for specifying the correct type of railway line. Or, if you want to preserve the data about the masts then changing the node tags from power=tower to power=catenary_mast is perhaps a viable solution. See here if you want to read up on what some "railway experts" think about tagging electric lines in OSM

Those screenshots show exactly what I would call "bright clouds at night". To me (and many others) BOTH default and SMP are unrealistic in this respect as the night clouds seem modeled as if they were illuminated from terrestrial light pollution (like over big cities). BUT: The good thing with the default clouds is that they can be tweaked to be even darker - hence my reference to the LUA script. It's only with that script that the default clouds look correct to me.

Thanks for the pointer, that's probably it - assuming that the plane's shadow is no different than any other object's. In any case, now the issue has its own thread

Don't know if anybody else has this, but in my case all ground objects (trees, buildings, ...) suddenly cast very weird shadows once they are within a cloud shadow area. It looks like the light source direction is affected by the current location, hence moving around causes the object shadows to change direction as well... The shadows return back to normal as soon they no longer fall within the cloud shadow area. I'm on Win7 and XP 10.30b8 64bit using an NVidia GPU. I have HDR enabled and global shadows set to "low" in the rendering settings The effect is perhaps best explained in a video so maybe I will try to upload one later today (as well as provide more comprehensive info regarding my settings and the NVidia driver version) as I'm currently without access.

The annoying bright clouds at night are definitely a downside compared to the current built-in clouds (10.30b8) for which additional tweaks exist, like for example the excellent Night light transition and white clouds LUA script. Unfortunately, these tweaks don't work with the SMP clouds... For that reason I'm often reverting back to the default clouds when I plan to go on night flights - even though running the SMP (un)installer repeatedly becomes a PITA rather quickly...