RyanRising

What now? Seems like this dev cycle has been more arduous than most. I expect you'd want to lie down.

I still haven't entirely gotten over Superheavy losing its legs, but the ship being crippled too is a bit much for me. I should stay off the Internet for a bit.

That's a lot more courteously stated than I would have done, but this sums up my thoughts perfectly.

You can walk through some amount of gravel, provided you have shoes on. You’re not phasing through the grass in my example either, you’re pushing it aside, even though games don’t model that either. The reason I make this comparison is they’re all visual details that technically should have some physical effect on a vehicle moving through them, just not much. Small rocks would probably be scattered away from a small wheel and driven over my a large wheel without any noticeable change in its path, but I don’t mind if they’re static since modelling them as movable objects may be too expensive on a game that will already have a rather taxed physics engine. That being said, I’d love to see different types of terrain, which could include a sort of gravel that makes it more difficult to get traction with wheels and is visually represented by dense patches of these small, non-collideable rocks.

For all you worried about performance, it seems pretty clear you’re not going to get this game running well on a machine whose GPU struggles with KSP1. There’s so much more detail here, and it’s just a game that started out later. It’s not going to be made for the same sorts of PCs. However, KSP’s issues with performance, as far as I’m aware, have almost always stemmed from the physics or handling of large-scale player-created structures and systems. I think a reasonable expectation is that KSP2 is, at a base level, harder to run smoothly than KSP1, but as you build up large crafts and bases performance doesn’t decrease anywhere near as drastically as it did with the first game, and at crafts with large part counts KSP2 actually does run smoother than the equivalent craft and situation in KSP1. Also, as for a solution to pop-in on airless bodies, I’ve seen some games that have detail slowly rise up from underneath (or the visual ground level sinks down to reveal it?) less detailed meshes as you get closer to it, usually far enough away and subtly enough that it’s not noticeable. I imagine that would be a workable solution here, though I’m still thinking in terms of “up and down,” whereas if there will be caves and overhangs it would be more suitable to have the detail “grow out” from less detailed meshes (or the less detailed mesh “shrink” to reveal new detail.) I disagree. Clouds in most games aren’t collideable, nor is grass, but I nonetheless appreciate having them both.

Pretty smooth. As always, I wish we had rocket cams, but the telemetry's a decent substitute - no shortage of info there. And, of course, it's always nice to see these things go off without a hitch.

Just to further clarify this point: not only is Starliner never going to the moon, it was never supposed to go the Moon. It was designed and built to only operate up to Low Earth Orbit, and it has maintained that purpose throughout its development. It's possible that modifications could be made to the spacecraft to give it lunar flight capabilities, but Boeing has not expressed any interest in doing so.

I don’t think it’s fair to say Dragon has worked perfectly on every flight - I both remember talk of thruster heaters not functioning and higher than expected rates of ablation on the shield, as well as DM-1 perhaps having a problem similar to Starliner on its first flight but being able to recover and dock anyway. (If anyone has more info on that specific occurrence, I’d love to have it. All I’ve heard are whispers, so it may not be true at all.) However, it has always worked well enough, which is a much higher bar than working well enough is for Falcon recovery or especially Starship prototypes.

Thank you!

I know this has been said before, but even without Starship it never would have held that title.

Does it? IIRC the Waterfall sounds apply over those from RSE, I had to go into the configurations and add some :NEEDS[!RocketSoundEnhancement]s in there to get RSE's sounds and Waterfall configurations not to step on each others' toes. That said, it was a pretty simple fix and I am most certainly enjoying the experience.

I was under the impression that on-the-spot suggestion was to use ullage gas as the propellant storage for the ship's hot gas thrusters, not to not burn it at all, but looking back at it I don't think it's clear either way. At any rate, this interview certainly is one heck of an info dump, so many questions I had are already answered!

While it is nice to see this update and fixes, I can't find mention of the robotic drift issue in the patch notes. That was the fix I was most looking forward to in this update. I hope that's something that can be addressed sooner rather than not at all?

Heard rumours that the grid fins won’t fold down for ascent, but will stay in that extended position the whole flight. I hope the guy who told me that just had bad info, cause that is properly cursed. I know passive stability isn’t even a consideration on modern-day rockets, and on Starship especially would be a lost cause, but picture the whole stack flying up with the grid fins out and tell me that doesn’t just look wrong.

I think you mean “it may still house many interesting and invigorating problem-solving challenges.”

So they’re not trying to give the VAB a run for its money just yet.

Might help me see some stuff that's obviously wrong if so, but honestly it's probably not necessary. As long as you have the folders Squad, Waterfall, StockWaterfallEffects, and the file ModuleManager.4.1.4.dll in there it should work, assuming you don't have Restock. I'd more like to see a screenshot of the plumes not showing up, cause that would tell me what engine you're using. I still might not be able to fix your problem, but it could point me to something else.

Oh, whoops, so it has. Thanks a bunch.

I probably should have mentioned this here before opening an issue on GitHub, based on the FAQ, but does anyone else see this Z-fighting-like behaviour with the boattail variant of Restock+’s KR-1 “Boar” engine? It doesn’t come across well with still images, but those black patches dance all over the shroud in all but a few places.

You’re likely installing the mods incorrectly. What does your GameData look like, and can you provide a screenshot of the lack of plumes?

There's only one ModuleManager: It does have different versions, but you should be fine using the latest one, 4.1.4 at time of writing. It's a .dll you can drop in your GameData folder.

What engines are you using? Mecripp was saying you may be using engines that haven’t been patched to use Waterfall. Some part mods will include their own patches, some will not. Patches, in this context, are modifications to existing things in KSP. ModuleManager is the thing that handles them, and they come in the form of .cfg files. In this case, the patches delete the particles and sound coming from an engine in KSP and add new sounds and the Waterfall plumes to them. If you’re just using the stock engines, the patches you want will need to be downloaded separately from Waterfall. That’s StockWaterfallEffects if you don’t have Restock installed and WaterfallRestock if you do. They’re available from links at the bottom of the first post of this thread.

Are the recent-ish commits I see on the GitHub part of those dreams?

@linuxgurugamer I've been playing with this mod, and I noticed a consistency issue that wasn't present in the original version as far as I can tell. The Prograde and Retrograde tracking in warp appear to function differently than the earlier-implemented "Stability Assist" SAS mode. That one will track to your set body, as do the others as far as I can tell, but only if your rotation speed is low enough. If you're spinning quite quickly, the attempt to hold attitude will fail and you'll continue to spin. This appears to be consistent with the mod's goal of making momentum and rotation more realistic, as stopping that rotation would require significant resources*. However, the Prograde and Retrograde hold do not conform to this standard - they instantly fix your craft to that vector upon entering warp, killing rotation for free in the same way stock timewarp does. This will persist upon exiting timewarp if you do so still set to that vector. Is there a way to make these modes more consistent with the premise of the mod?

If you read the thread title, you may find the answer is yes.