RyanRising

It’s a JNSQ problem - the configs aren’t updated for the new scatterer version, though someone has in either this thread or the JNSQ one posted basic configurations that are.

So no cloud scattering for these babies with MSAA on the ship? Bummer. Still, fantastic to see you doing this even if I can’t personally take advantage of how good it looks!

That tweet seems to be deleted. Does anyone have the image?

For someone not well versed in shaders, what does it mean that the additive blend mode is One One?

I will admit, it's not completely useless - if you never unlock docking ports, they now work as well as they did pre-1.12. That's something. But I do think @JPLRepo glossed over an important point in the devblog that makes this fix much less effective than it would otherwise be - that the robotic parts still save their and all the craft's parts' physics-modified positions upon locking, meaning simply locking robotic parts when you're not moving them won't fix robotic drift. Only never unlocking them will.

Ok, after some initial testing with docking ports it doesn't look like the issue is fixed at all. I put two docking ports together and put two ore tanks underneath them to provide a load, suspended the thing from launch clamps, and toggled the rotation unlocked and locked again for both. Then I quicksaved and quickloaded, and in rails timewarp the docking ports had a space between them despite being locked - exactly as expected for the robotic drift bug being still there, and exactly what I would not expect to see had the bug been fixed. A little more testing shows that drift does not affect vessels that have robotics parts but are never taken out of the locked state. So this might work for docking ports if you don't touch them, or for robotic parts which are never used.

I thought this was gonna just be an issue that stayed forever! Thanks so much for putting together this fix. EDIT: Or maybe it still is? Haven't been able to test the patch yet. I thought for sure it'd do what it said on the tin.

Yeah, but I wouldn’t have to use TAA if MSAA is available. I actually don’t have TUFX installed - probably worth a shot. EDIT: The implementation there doesn't seem fantastic either.

Ok, but, like, can I do anything about it? Or do I just have to go back to 0.0772? EDIT: I mean while keeping some antialiasing other than SMAA, which does not look very nice.

@blackrack Whenever you have time to look at this, I've noticed an issue with atmosphereless bodies in the latest release of Scatterer with TAA enabled: The bodies seem to "smear" as if the antialiasing doesn't realise the bodies or camera are moving around. This is cleared by other things, like the skybox or a vessel, as well as sometimes certain regions of the screen? Images below: To reproduce, what I did was get a new install of KSP 1.12.2, install scatterer v0.0825b (and the blue crafts fix), start a sandbox game, go into the scatterer settings, set the preset to "high," then turn SMAA off and TAA on. Then I cheated a simple craft into low orbit of an airless body. I'm not sure the "high" preset is necessary, nor is cheating. log is here, if it helps: https://drive.google.com/file/d/1rN-kLg_vgcSh8n4inPy67kGwHUCPCWq-/view?usp=sharing

Thanks a bunch! It works now - some planets are still a little weird, but it's by no means unplayable now.

You could always just use an older version of scatterer, that works alright for the time being.

I've tried this on my main JNSQ install and while some of the atmospheres seem to work better, I still see the black Jool and Lindor, as well as an apparently unlit Eve and Huygen (not sure if the clouds are there? I suspect not.) This is with KSP 1.12.2, the latest JNSQ, Scatterer, and EVE-redux. Here are some images: https://imgur.com/a/NnhCKDQ Here's my log, in case it helps. https://drive.google.com/file/d/1WnF-CAn6O7uHMOjmduTmchHCCE-zXvbA/view?usp=sharing

It's pretty satisfying to know my estimate of "a little more than 10 extra seconds for an equivalent engine" has a sound grounding in the math, despite me doing absolutely none of the work to verify it. Thanks for actually checking!

Have you seen Rocket Lab's headquarters? He was already way ahead in that respect. I suspect it's just the sea level engine running in a vacuum. The Merlin 1D (sea-level) should be roughly comparable, same cycle, modern tech, and that has ~310 s in a vacuum. That means between equivalent engines, you gain ~10, 15 seconds of specific impulse by going with methane over kerosene. Raptor is such a stupidly high-pressure engine, and is positioned so early on in the timeline of methalox launch vehicles, that it makes the performance benefit of methane over kerosene seem a lot higher than it actually is. I tend to think Rocket Lab went for methalox not for Isp, but for the fact that methane is cleaner-burning than kerosene, and so will leave a lot less nasty deposits in the engine. ...not none, methane still can be made to coke, just a lot less than kerosene which has the long chains of carbons all ready to go before they get jumbled around.

Skull and crossbones on the truck probably gives it a certain appeal.

This is that video un- (or less, at least) cropped. And as to the question @rocketrundown asked, I very much doubt a camera is moving at all to capture that, rather we're seeing a small section of a taller video being scanned across after-the-fact.

The clouds also don't appear to change colour with sunsets, but that could be the configs just showing their age - JNSQ's scatterer and EVE integration has not been updated in quite a while. Right, full bug report. Gotta spin up a clean install. ...or not? hm. It's kinda late rn, someone hit me up tomorrow.

LGG isn't adopting this too, is he? It's far too soon!

“A novel electromagnetic propulsion system” sounds interesting. I know magnetorquers are a thing, I guess it stands to reason you could try to propel yourself using the same idea? and if so, that might explain why they wanted a particular orbit - could be where that system would best be able to demonstrate its abilities within the X-37B’s range?

It doesn’t, and this is well documented in the bug tracker. That’s not to say that R-T-B needs to take that as a go-ahead regardless of whatever Squad says, esp. cause they might not be under those laws’ jurisdiction. There really does need to be an official address to this problem, preferably one that allows modding to continue. EDIT: plus that isn’t how those laws work, as documented below

I wonder how useful these numbers are - with crew, a good chunk of that 27 of 38 tons is taken up by Orion itself. My initial thought is that the important numbers for the crew variants are the comanifested payload, but maybe Orion's mass can vary substantially?

Expand, perhaps?

It’s wonderful.

Since you asked, I believe the RAPIER isn't handled well here - Restock remodels the engine, but WatefallRestock doesn't have a configuration for it, leading to the StockWaterfallEffects effects being applied to the Restock model. The result is a plume that's offset from the nozzles and slightly off on scale.