GJdude

It does indeed, strange for these particular ones to be included on the cargo parts but they're there. They are the three resources that hydrogen/oxygen fuel cells use - fuel cells which are present in BDB. I tried to have a go at adding some resources to them but couldn't wrap my head around it at all, unfortunately.

Found a fun oopsie for the USI Life Support compatibility configs, notably there's two of them, one called "Supply" and one called "USI-LS". Both seem identical though one is slightly larger and various things are being applied twice, like flavour text and hab modules and the likes. Simply deleting one of them is the fix for that, tried it myself. There was also this happening: But I'm getting the idea that these resources aren't coming from TAC and are supposed to be on the cargo parts since they can be used with certain kinds of fuel cells, including the ones I'm getting from having Universal Storage II installed. In which case, I still feel like there should be more USI resource options for these cargo parts since that's the main thing you'd be bringing up to a manned space station - Supplies or Fertilizer and the like. Some of the old versions of these parts had it so if it's planned to be added in a coming patch then that's fine.

Poor TAA really can't catch a break, can it? It's a shame MSAA had to be so disagreeable with the new rendering methods. For now the only fix appears to be others modifying waterfall configs to distance the meshes from the engine bells a little more, but that could be a quality compromise for anyone not running scatterer and isn't entirely confirmed to work yet. If anyone finds out the cause of this interaction, they'll need a medal. For now I'll just stick with SMAA before my stubbornness to try and solve this drives me insane, since it's really the only incompatibility problem left after previous updates. What a perplexing issue!

I can confirm that the z-fighting flickering interaction with waterfall plumes and any form of TAA is still present, but falling back onto SMAA really does sting since the newer TAA looks very nice. What levels is SMAA working at currently at the different quality levels? Even at 2 it doesn't feel like enough for 1080p. Is this 2x? 4x? Does SMAA even work like that? My rig can certainly handle turning it up to 8x or however high it goes. Could those of us still wrestling with this interaction get the option to turn SMAA up higher, if possible?

I've rolled some things back to a version where I can disable the depth buffer-based rendering entirely now, but if I get back to a newer version in future and this occurs again, I'll definitely look further into it.

That seems to have done the trick, yes! Edit: Or not. At first things were fine but now it's back again.

Despite disabling it in exchange for SMAA in the settings, TAA is turning itself on in flight whenever I open the map view, and only a scene change (like opening the tracking station or KSC) seems to turn it off again. I had a feeling it might be reverting itself to the High quality setting, which I was running before the custom changes, but when I went into all the presets in the default config itself and swapped the AA in the higher ones, it still persisted. I know TUFX has an issue with turning it off when the map view is opened, but I'm not using TUFX. Is anyone else seeing this? Could it be something in AVP doing it?

I admit I was a bit disgruntled writing the original post, in hindsight I could have boiled it down to less. As for the shadows, that's exactly why I wanted your word on that. I was wrong, which is why I wouldn't trust myself an inch to be writing any documentation.

I get where you're coming from, people do tend to search up their problems, but I think a forum search is still a slower process than it being front-and-center to read as a small disclaimer for as long as it continues to be a thing, for those who install mods manually. If the way a mod works induces some side-effects by default, users have a right to be informed of that somewhere clear - could save them a lot of time slowly disabling mods to filter down where the problem's coming from if they decide to check the front pages of their visual mods to see if any of them mention it first. Not everyone will do that of course, but it'll help a few, and for those who search about the issue, it's already been covered in previous posts here. I have had an idea for blackrack's consideration, though. Would it be technically possible to implement higher 4x or 8x levels of SMAA in the future? I'd imagine that may well entirely resolve the issues with disabling stock AA, since it'd be replaced with more lightweight and somewhat equally capable options with the same quality levels offered.

All I'm really proposing is a couple simple notes on the main page saying the mod disables default AA and starts on a lower quality setting, there's no need for third-party documentation to be written up on that which would need maintaining by me through any future updates that change the matter, I could easily get something wrong. I didn't make scatterer, and I'm not a modder. I had to google around the place for an hour just to find out what was happening to my game. Best for it to come from blackrack, who actually knows how the mod works. It's all just a suggestion, really. I'm not sitting here with a big pitchfork demanding any of this happen, just in case I was giving off that vibe.

I've come to harbour a few grievances about how some of scatterer's features and settings are currently being handled, so I'll just lay it out here. For the average end user installing the mod in its current state - perhaps as part of a visual pack without even knowing what they've signed up for - they're immediately going to be asking two questions. "Why does my antialiasing look bad sometimes" and "Why do the vessel shadows look bad sometimes" They're going to start scouring the universe looking for solutions to what is assumed to be some sort of a stock rendering bug and potentially doing their game even more harm. It isn't clearly communicated almost anywhere outside of old release notes and forum posts that the new depth buffer mode disables default MSAA in certain scenes due to incompatibility and replaces it with SMAA (and I don't know if it's just a me thing or a 1080p issue, but it's looking pretty awful on my end even at higher quality levels), or that the mod defaults to a low quality setting - increasing which improves the shadows. I understand both these changes were made for performance and compatibility's sake, but they also cause their fair share of problems for the unaware user - especially if the new depth buffer mode can't even be turned off now. Even a single in-game settings change (which people do far more often than you'd think) will be enough to re-enable the stock AA, which causes some visual bugs. Again, few people would have any idea of this being a thing until it happens, potentially by accident, leading to more unnecessary bug reports and the like. There should be more information on the main post explaining this, and if possible the ability to disable the mode should be kept for those who prefer visuals over performance like myself. I have a good GPU, I like my MSAA and I'd prefer to be able to keep it on without having to rollback my Scatterer, EVE, and AVP versions.

Forcing glcore saves a stunning amount of ram use, even if it costs a little fps. My install goes down from hogging about 14+ gigs of ram down to about 8 or 9. I have 16 gigs of ram, which should be enough for JNSQ, and I've tried cutting down my modlist several times, and yet KSP still demands on throwing itself right to the limit and forcing all manner of occasional page file slowdown unless I use glcore. I've always wondered, what does glcore do to save ram that DX11 can't do?

Ah. I heard way back when that it was better for performance, noticed it dropped the ram use by one gig and never went back. Turns out the bug isn't visible when running the default DX11. I guess we just found a new OpenGL bug.

I value my RAM and FPS, and OpenGL gives immense gains to both. I tried switching up the values as suggested in Kerbin's ocean.cfg (I believe that's the right file) and alas, it's still there.

After some more experimentation I narrowed the atmosphere issues down to Scatterer, so don't worry about that one. As for lindor, the rings are still pink. Here's my log. Edit: Turns out this occurs when forcing OpenGL. Still don't know what else is behind it, though.