blingthinger

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.

Excellent build-up upon what I said. But no thank you for putting words in my statement that are neither present nor intended. "Should" will be derived from "need" simply because they won't be selling as many copies of their app. Adapting (I do like your use of "optimizing") is certainly going to require using new driver tech and advanced coding techniques. Much the way LR is working towards motion vectors and more modern resource usage. These are various statements of adaptation. How you magically injected "stop advancing" into my statement is truly bizarre. The 3rd party dev who responds with "no, go buy more ram" will simply not receive as much revenue as they refuse to adapt to current market conditions (which will last for a long while I'm afraid).

LR dev population is no longer 100% mac. Been a mix of all 3 OSes for a long while now. In fact, their current networking guy used to work at Ubuntu. 16 gig should not lead to a CTD. It won't have the best performance and visuals, but it should not crash. Especially not the entire OS (if that is what's happening). The game/sim world needs to adapt to the new normal of folks not being able to afford to update their systems as often as they have for the past decade or so.

Hung system? As in the entire desktop freezes and you have to reboot, simply because you loaded that aircraft? If the system was running out of RAM the OOM killer should have triggered and force-closed the sim. Is that not happening? I can't recall what distro you're on, but does it have zram enabled? You can check that with 'zramctl' (install it if needed). It will return some basic usage stats if that is active. If it is active, make sure it's set to 1xRAM size. You could also experiment with 1.5x. If you are getting OOM killed even with zram enabled, it might be a simple matter of creating or increasing the size of the swapfile. Or creating and then turning on a swapfile if you already have a swap partition. That said, if you find that the system writes to swap a lot, you should switch over to zswap instead of zram (if you're not paranoid about someone stealing secrets from your swapfile if the pc ever gets stolen from your home). zswap is smarter than zram but is only needed if the swapfile/partition gets written to a bunch.

Mmm no that has nothing to do with it. It's not LR's fault. The sim downloads realtime wx files from US gov. The distribution servers that XP uses are down and I imagine will likely stay down for the rest of the day because it's the weekend. Historical wx does work. That server is LR's.

Just me? No it's very clearly stated in the interview. I assumed everyone sifting through this thread would have also read the article in the OP link. My bad. "Moving into payware is obviously a big step. Was that a difficult decision for you? ... we are not exactly “selling” the product. We are simply asking for a small download fee to cover our costs and to help keep the other downloads free. It is more or less a form of donationware...."

"Issue" meaning that you absolutely will not be buying the Pro version? As in... your eyes are generally unable to de-focus from the blurry ortho that almost nobody actually ever sees (unless they run on 10 yr old hardware or laptops) and re-focus on the autogen buildings and their textures (the actual product in question)? You sat there staring, screaming a little bit inside your own mind? I too noticed the blurry textures. I thought, "at that altitude the XP default textures probably look better", but I can't say that it triggered any "issue"-like response. Certainly not to the level of balking at the actual product.

There's no intent to actively sell or market this. He's not even proactively looking for kindness tips. Just looking to cover server costs. He doesn't care one bit what the terrain textures look like in any "promo" video or if anyone doesn't download it. A true hobbyist.

You must have another layer injecting it somewhere. Deleting 1400 and 1401 removed all the airport vehicles on my install.

If sigma is the primary knob it's turning to tweak Dryden's equations, it's going to remain pretty close to what IRL data sometimes looks like. Spectrum plots in Fig 7 look pretty darn similar to the polynomial equations that Dryden came up with. https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2022JD037491