blingthinger

Sure this is the big question and I'm sure they can provide many reasons why it hasn't happened yet and none of them will fully satisfy the users. It will come along eventually. It's certainly long overdue.

Sounds like someone who is retired from daily work life! I'm sure the 60,000 employees that microsoft is currently targeting to kick out of the company are thrilled with the current developments. As is Adobe and the other software vendors who are currently being cloned out of existence. The upcoming societal adjustment period will be a wild ride with a fair amount of negativity. Maybe you are referring to an old version of the plugin description? The current posting clearly states "connects directly to the rendering pipeline" and "changes how X-Plane draws every frame". Any vulkan layer-based app will be against LR's guidelines, though there's nothing they can do to stop it....other than finally finish their own implementation.

Does beta 5 fix this?

50% If only... some applications actually run faster without it. XP used to be one of them but LR made some changes a couple versions ago that make it SMT/HT friendly. You won't notice any performance loss by turning that stuff off though. Only place you might notice it is during scenery loading where waiting for disk i/o makes sense to context switch on the CPU. But it's nowhere near 50%. More like 10-15%. SMT/HT is not a magic doubling of cores.

I see something like that occasionally. Sim becomes unusable. When it happens I pull up the microprofiler window and see tons of VRAM processing activity. Hadn't ever correlated it w/ AEP though, so that's interesting. It's always temporary too. Lasts maybe a minute on my system then goes away.

They took it down because BATC announced official XP12 support as you say, and they didn't want to conflict with them. More out of respect, it seems. Check the now-edited reddit post: https://www.reddit.com/r/Xplane/comments/1wyxc94/beyondatc_working_in_xplane_12_unofficial_bridge/

I don't think +2gb is going to magically make the blurries go away with those addons in use. Lots of folks complain about seeing it even with 8gb. If you aren't cpu limited, you'd certainly see a FPS increase though. A while back they posted a roadmap of tech that would be going into the gfx engine. There was mention of stuff that would definitely help VRAM budgeting and usage. Probably linked to the next-gen scenery engine. Maybe wait till you see that stuff go into the sim? Who knows how long that will take though. They did say that initial next-gen stuff would start arriving this year.

They will need to if they ever do want to make it into the Level-D sims industry like they claimed a couple yrs back. It's on the list. I also think I noticed that near-layer clouds cast SSAO onto the layer below. Maybe. I'll have to pay more attention next time it's booted up.

What a wall of off-topic rant. I've never claimed credibility like you obviously need to jam in our faces. Enjoy your self-dug hole. All you had to do was say "no no, I meant nothing by it....nobody's a rat here". You desperately wanted to argue. Or irrationally accuse, one of the two.

My hole? That's just general internet caution. But nice hole-plunge by trying to offer proof. I couldn't care less there because in this case what it really deserves is actual data (picture, video, RVR data, etc) comparing either or both of them to reality. Also odd that you refuse to offer specifics about why you retain Autohaze. I don't use it (plugin minimalist) and therefore have no opinions either way until I see some data. I do like seeing that the ground remains obscured above the layer with the default LR model. I presume Autohaze would behave the same way? I have yet to travel towards an outer boundary of haze and turn around to see if the distance-where-I-came-from remains obscured or if it clears up, akin to what flying above the haze used to do.

In this case, not even a little bit. Especially given that you are now just as "off-topic". Someone made a statement very much associated with Autohaze, it's author, and LR's new feature in 12.4.4. It fully deserved curiosity. If that person had simply said "no, no, I meant nothing by it, I was just being silly", the curiosity would have ended right there. Now we do know that it was just silliness and not accusatory as that phrase generally is meant to imply. Now...you simply tossing out a claim of PPL (which everyone should think twice on because this is the world wide web with ai and all) does nothing to boost your credibility in judging what haze should(n't) look like. So what exactly do you find inaccurate about LR's implementation?

None at all. You misunderstood my comment. fluffy seemed to imply that you were somehow the reason I stopped probing about the intentions of "I smell a rat". You weren't. That's all I meant there. Congratulations! Good for you!

Not that I've seen though it's not a 3d volumetric cloud/layer. I have yet to fly to the edge of a region that has really low visibility (like pollution filling a mountain valley) and turn around to see how the view changes. And there's a notable color banding thing going on as you move in/out of it. Identical to the color banding present in the late/early dusk/dawn sky.

I didn't see this post. There's no anti-ai here. Where are you seeing anti? I simply referenced that you used it and therefore have zero claim to authorship if there was ever some sort of claim that LR directly "stole" the lua process or even code. Given that there actually is no actual "rat" accusation (it was apparently just silly nonsense chatter) and therefore no authorship claim either way, you're good in my book. Where I do find in error is when folks don't admit it up front. You have done that, so no worries. Otherwise you'd be seeing me posting about it elsewhere and you don't see that.

You can't see the ground when above the haze layer if that's what you're referring to. Where is LR's implementation lacking? Thus far I read some hand waving that yours is better but no actual comparison between the two methods. Believe me: Mr Mackie was of zero assistance.

You made a statement that is 99.9% slanderous but really didn't mean it that way? That's fine that you can't admit error, so I'll add in another option for you: you're expressing solidarity for a creator? Just with the wrong word. Note here that LR also knocked out another plugin creator with this release (snow coverage). Not only "knocked out" but called them out in the blog post. Literally saying "do not use that plugin anymore". But I have yet to see your logic behind "rat" and you refuse to even attempt to cough any up. There was no targeting here with the atmospheric visibility. It's 2 fewer plugins that folks have to worry about. That's not a problem for anyone unless.... the plugins did/do it better. Certainly still room for discussion there.

Oh by all means: elaborate on what you meant here then. I'm all ears. You may very well be the first time I've ever heard someone use "rat" as a compliment.

From the text you quoted at the start. Did you not read it? And the plugin is well known to be ai coded. Where in this timeline are you so wildly confused?

Rat? Where? How? Improved capability sure, but the notion that LR dug through the lua plugin and copied it is rather amusing and baseless. There are plenty of public data sources out there and as I recall, the plugin is going to a web source that provides the visibility value directly. LR is deriving it from a range of other atmospheric data. Plus, given that autohaze is ai-generated there's zero ability to claim "authorship" in the first place.

oops my bad for thinking you actually might have been somewhat interested in debugging the issue in addition to pure 100% pointless rant. But here's one last whack before you send it to the glue factory: boot into a live usb distro (e.g. latest ubuntu or endeavourOS) and try it there. And if it still fails there, start the sim in gdb and check the stack trace after it freezes. Where does it fail?

Hey if that's how you folks need to label the scientific method, so be it. I have also spent enough time in and diagnosticating the land of linux to know that that explanation isn't passing the sniff test.

Not yet. There's no firm evidence. Circumstantial? Yes, but that's not enough to convict. Addon acft don't take down an entire OS unless there's some odd library issue or maybe something in the kernel. Maybe in that sense, it's a simple as starting the sim with the command line arg --zink to force on the zink layer. None of that is necessarily a dev's fault. Thus far we've heard that ram and cpu usage are possibly the culprits but no actual data to implicate either (rant != data). 100% usage of either of those doesn't take down an OS unless there's hardware failures or overclocking in the mix.

It's as if nvidia is vibe coding their drivers these days. Seems like it's a perpetual mess now. This is something Coastaldriver should try out. Per his own description, it's obviously not RAM exhaustion and simply loading up CPU usage doesn't lead to a full system hang like he's describing. He's blaming a 3rd party dev for his own system issues. Unfortunate. Most mainstream distros provide ability to revert nvidia driver version. They don't usually have that capability for Mesa because Mesa is quick to fix any bugs. And somehow AMD does a much better job of maintaining their linux kernel-space drivers than they do in windows, or than nvidia does in general right now.

You're all over place here. First it's ram, now it's cpu. I'm not convinced that this is the dev's issue.

Checking dmesg output will tell you if it was OOM situation. Unless it involves a reboot. Check up on the zram/zswap options I mentioned above. If it is OOM, that will resolve it. Otherwise bite the bullet and start running RAM stability checks and pray that it's not a hardware failure.